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

[Andrey Bokhanko via llvm-dev]

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.

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.

Yours,
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210708/a5195572/attachment.html>