llvm dev - Jul 2021 - RFC: Sanitizer-based Heap Profiler

On Thu, Jul 8, 2021 at 8:56 AM Andrey Bokhanko <andreybokhanko at
gmail.com>
wrote:
> On Thu, Jul 8, 2021 at 6:25 PM Teresa Johnson <tejohnson at
google.com>
> wrote:
>
>> Responding to this one first, I'll respond to your other email
shortly.
>> Initially we plan to provide hints to tcmalloc via new APIs to help it
make
>> allocation decisions (things like hotness and lifetime). The compiler
will
>> be responsible for adding these hints, using some method to
disambiguate
>> the calling context (e.g. via function cloning, new parameter, etc).
>>
> Sounds good -- thanks!
>
> (though this would increase code size and thus, instruction cache pressure
> -- tsk, tsk... :-))
>
There are various methods for disambiguating the contexts (e.g. HALO
inserts some instructions at a minimal number of callsites to do this), and
I suspect a hybrid method will be best in practice. E.g. cloning for hot
allocation contexts or callsites, and instructions or parameters or
something else on colder allocation contexts and callsites, to balance the
code size and dynamic instruction overheads.


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210708/02f8bd95/attachment.html>

Sorry if I sounded too demanding: the easiest thing in the World to do
is to sit on a sofa and throw one demand after another... :-)

I understand that you have a big field full of question marks in front
of you and an immensely challenging task. My "tsk, tsk" message was
said with a tongue in cheek.

On Thu, Jul 8, 2021 at 7:04 PM Teresa Johnson <tejohnson at google.com>
wrote:
>
>
>
> On Thu, Jul 8, 2021 at 8:56 AM Andrey Bokhanko <andreybokhanko at
gmail.com> wrote:
>>
>> On Thu, Jul 8, 2021 at 6:25 PM Teresa Johnson <tejohnson at
google.com> wrote:
>>>
>>> Responding to this one first, I'll respond to your other email
shortly. Initially we plan to provide hints to tcmalloc via new APIs to help it
make allocation decisions (things like hotness and lifetime). The compiler will
be responsible for adding these hints, using some method to disambiguate the
calling context (e.g. via function cloning, new parameter, etc).
>>
>> Sounds good -- thanks!
>>
>> (though this would increase code size and thus, instruction cache
pressure -- tsk, tsk... :-))
>
>
> There are various methods for disambiguating the contexts (e.g. HALO
inserts some instructions at a minimal number of callsites to do this), and I
suspect a hybrid method will be best in practice. E.g. cloning for hot
allocation contexts or callsites, and instructions or parameters or something
else on colder allocation contexts and callsites, to balance the code size and
dynamic instruction overheads.
>
>
> --
> Teresa Johnson | Software Engineer | tejohnson at google.com |

On Thu, Jul 8, 2021 at 9:04 AM Teresa Johnson <tejohnson at google.com>
wrote:
>
>
> On Thu, Jul 8, 2021 at 8:56 AM Andrey Bokhanko <andreybokhanko at
gmail.com>
> wrote:
>
>> On Thu, Jul 8, 2021 at 6:25 PM Teresa Johnson <tejohnson at
google.com>
>> wrote:
>>
>>> Responding to this one first, I'll respond to your other email
shortly.
>>> Initially we plan to provide hints to tcmalloc via new APIs to help
it make
>>> allocation decisions (things like hotness and lifetime). The
compiler will
>>> be responsible for adding these hints, using some method to
disambiguate
>>> the calling context (e.g. via function cloning, new parameter,
etc).
>>>
>> Sounds good -- thanks!
>>
>> (though this would increase code size and thus, instruction cache
>> pressure -- tsk, tsk... :-))
>>
>
> There are various methods for disambiguating the contexts (e.g. HALO
> inserts some instructions at a minimal number of callsites to do this), and
> I suspect a hybrid method will be best in practice. E.g. cloning for hot
> allocation contexts or callsites, and instructions or parameters or
> something else on colder allocation contexts and callsites, to balance the
> code size and dynamic instruction overheads.
>
Right -- static disambiguation is suitable for hot allocation sites which
are sensitive to any overhead added.

David
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210708/ce0f127f/attachment.html>