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

Hi Andrey,

The compiler side support for the necessary instrumentation went in a while
back (D85948), as did the compiler-rt support (D87120 is the main one, but
there were a number of preparatory and follow-on patches). Currently it
dumps to a text file. We've been working on designs for the binary profile
format, IR handling for the profile data, and context disambiguation
support. We plan to send RFCs for some of this early this quarter.

We initially plan to use the profile information to provide guidance to the
dynamic allocation runtime on data allocation and placement. We'll send
more details on that when it is fleshed out too.

Teresa

On Mon, Jul 5, 2021 at 7:02 AM Andrey Bokhanko <andreybokhanko at
gmail.com>
wrote:
> Hi Teresa,
>
> A year has passed since you posted this RFC; could you, please, give a
> quick update on the current state of heap profiler development?
>
> (Sorry if you already did so; I looked through llvm-dev mailing list
> to no avail -- but perhaps I missed something?)
>
> We (Huawei) are very interested in data cache optimizations; we are
> discussing our plans with Maxim and others on the BOLT project github
> (https://github.com/facebookincubator/BOLT/issues/178); I would be
> really interested to hear your perspective / plans -- either on BOLT
> project discussion or here.
>
> One area of particular interest are specific data cache optimizations
> you plan (or not?) to implement either in compiler / binary optimizer
> / runtime optimizer based on heap profiler data.
>
> Thank you!
>
> Yours,
> Andrey
> ==> Advanced Software Technology Lab
> Huawei
>

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

Hi Teresa,

Thank you for the quick reply! I'm really happy to see the project is
moving forward!
> We initially plan to use the profile information to provide guidance to the
dynamic allocation runtime on data allocation and placement. We'll send more
details on that when it is fleshed out too.
Just to double check: do you plan to open-source this runtime? --
perhaps as a part of LLVM?

Yours,
Andrey

On Tue, Jul 6, 2021 at 12:54 AM Teresa Johnson <tejohnson at google.com>
wrote:
>
> Hi Andrey,
>
> The compiler side support for the necessary instrumentation went in a while
back (D85948), as did the compiler-rt support (D87120 is the main one, but there
were a number of preparatory and follow-on patches). Currently it dumps to a
text file. We've been working on designs for the binary profile format, IR
handling for the profile data, and context disambiguation support. We plan to
send RFCs for some of this early this quarter.
>
> We initially plan to use the profile information to provide guidance to the
dynamic allocation runtime on data allocation and placement. We'll send more
details on that when it is fleshed out too.
>
> Teresa
>
> On Mon, Jul 5, 2021 at 7:02 AM Andrey Bokhanko <andreybokhanko at
gmail.com> wrote:
>>
>> Hi Teresa,
>>
>> A year has passed since you posted this RFC; could you, please, give a
>> quick update on the current state of heap profiler development?
>>
>> (Sorry if you already did so; I looked through llvm-dev mailing list
>> to no avail -- but perhaps I missed something?)
>>
>> We (Huawei) are very interested in data cache optimizations; we are
>> discussing our plans with Maxim and others on the BOLT project github
>> (https://github.com/facebookincubator/BOLT/issues/178); I would be
>> really interested to hear your perspective / plans -- either on BOLT
>> project discussion or here.
>>
>> One area of particular interest are specific data cache optimizations
>> you plan (or not?) to implement either in compiler / binary optimizer
>> / runtime optimizer based on heap profiler data.
>>
>> Thank you!
>>
>> Yours,
>> Andrey
>> ==>> Advanced Software Technology Lab
>> Huawei
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohnson at google.com |

Hi Teresa,

One more thing, if you don't mind.

On Tue, Jul 6, 2021 at 12:54 AM Teresa Johnson <tejohnson at google.com>
wrote:
> We initially plan to use the profile information to provide guidance to
> the dynamic allocation runtime on data allocation and placement. We'll
send
> more details on that when it is fleshed out too.
>
I played with the current implementation, and became a bit concerned if the
current data profile is sufficient for an efficient data allocation
optimization.

First, there is no information on temporal locality -- only total_lifetime
of an allocation block is recorded, not start / end times -- let alone
timestamps of actual memory accesses. I wonder what criteria would be used
by data profile-based allocation runtime to allocate two blocks from the
same memory chunk?

Second, according to the data from [Savage'20], memory accesses affinity
(space distance between temporarily close memory accesses from two different
allocated blocks) is crucial: figure #12 demonstrates that this is vital
for omnetpp benchmark from SPEC CPU 2017.

Said this, my concerns are based essentially on a single paper that employs
specific algorithms to guide memory allocation and measures their impact on
a specific set of benchmarks. I wonder if you have preliminary data that
validates sufficiency of the implemented data profile for efficient
optimization of heap memory allocations?

References:
[Savage'20] Savage, J., & Jones, T. M. (2020). HALO: Post-Link
Heap-Layout
Optimisation. CGO 2020: Proceedings of the 18th ACM/IEEE International
Symposium on Code Generation and Optimization,
https://doi.org/10.1145/3368826.3377914

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