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

[Teresa Johnson via llvm-dev]

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

> 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.
>

Oh no worries, I knew it was said in jest. =). But wanted to note the
concern, which is totally valid, and that we've thought about how to
balance various overheads.
Teresa


>
> 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 |
>


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