[llvm-dev] RFC: Sanitizer-based Heap Profiler

Teresa Johnson via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 8 09:41:40 PDT 2021


On Thu, Jul 8, 2021 at 9:27 AM Andrey Bokhanko <andreybokhanko at gmail.com>
wrote:

> On Thu, Jul 8, 2021 at 6:59 PM Teresa Johnson <tejohnson at google.com>
> wrote:
>
>> I was actually just typing up a reply welcoming contributions and to
>> suggest you give the existing profile support a try - I realized I need to
>> add documentation for the usage to llvm/clang's docs which I will do soon
>> but it sounds like you figured it out ok.
>>
>
> Yeah, I can still read code -- believe it or not! :-)
>
>
>> It would be difficult to add all of this information for every allocation
>> and particularly every access without being prohibitively expensive. Right
>> now we have the ave/min/max lifetime, and just a single boolean per context
>> indicating whether there was a lifetime overlap with the prior allocation
>> for that context. We can probably expand this a bit to have somewhat richer
>> aggregate information, but like I said, recording and emitting all
>> start/end times and timestamps will be an overwhelming amount of
>> information. As I mentioned in my other response, initially the goal is to
>> provide hints about hotness and lifetime length (short vs long) to the
>> memory allocator so that it can make smarter decisions about how and where
>> to allocate data.
>>
>
> Yes, I understand that the task is very challenging and there are a lot of
> limitations / compromises to make all around.
>
>
>> Definitely interested in contributions or ideas on how we could collect
>> richer information with the approach we're taking (allocations tracked by
>> the runtime per context and fast shadow memory based updates for accesses).
>>
>
> I guess the best way to approach this is by trying real workloads and
> investigating what works and what doesn't. Would be happy to contribute to
> this -- please keep me in the loop and drop a line when you'll have
> something ready to play with.
>

Yep, absolutely! Definitely welcome the ideas, feedback, and any
contributions you are able to make.


>
> Our team is busy at the moment with BOLT improvements (ARM64, shared libs,
> Golang support, etc); after that, hopefully we'll be able to join data
> profile development efforts.
>

Sounds good. Thanks,
Teresa


>
> Yours,
> Andrey
>
>

-- 
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/cad90597/attachment.html>


More information about the llvm-dev mailing list