<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 8:56 AM Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com">andreybokhanko@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On Thu, Jul 8, 2021 at 6:25 PM Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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).</div></div></blockquote><div>Sounds good -- thanks!</div><div><br></div><div>(though this would increase code size and thus, instruction cache pressure -- tsk, tsk... :-)) </div></div></div></blockquote><div><br></div><div>There are lots of ways to control the overhead : 1) context merging if their properties are similar; 2) context merging if memory in each context is short lived; 3) context trimming etc.</div><div> </div></div></div>