<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Hongtao,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">> How are recursive allocation contexts stored? Wondering if there’s any recursive compression performed. For example, a tree-based construction algorithm may create tree nodes recursively. Is each tree node object modeled by its unique dynamic context?<br>There is no special handling of recursive calling contexts, we store the entire unique dynamic calling context as the identifier. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">> Will the contexts of a leaf function merged during compilation when the leaf function is not inlined? If so, where does the merging happen?<br></div><div class="gmail_default" style="font-size:small">During compilation, each allocation site may be annotated with one or more heap allocation info blocks each identified by a unique dynamic calling context. We will not merge heap profile information across unique contexts as one of our immediate goals is to distinguish between hot and cold allocation contexts. The mechanism to distinguish the allocation contexts involve cloning or parameterization and Teresa will present the details in an upcoming RFC.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 4, 2021 at 8:53 AM Than McIntosh <<a href="mailto:thanm@google.com" target="_blank">thanm@google.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 style="font-size:small"><br>>>I don't think the gc compiler even involves llvm as it is written in Go. </div><div style="font-size:small"><br></div><div style="font-size:small">Correct.</div><div style="font-size:small"><br></div><div style="font-size:small">>>I'm not personally very familiar with Go compiler toolchains and their roadmaps, but Than can probably comment.</div><div style="font-size:small"><br></div><div style="font-size:small">I don't see any reason why something similar to what Teresa and Snehasish are proposing couldn't be implemented for the Go gc-based toolchain (with a significant amount of effort)-- from my reading it looks fairly language independent.<br><br>True, as previously pointed out, the gc-based Go toolchain currently doesn't support ASAN and lacks any sort of PGO/FDO capability, but this is not written in stone.  FDO support, along with improving the compiler back end to exploit profile data (via inlining, basic block layout, etc) is something that could be added if need be. Go's priorities have simply been different from those of C/C++.<br><br>>IMHO, there is an intrinsic value of data formats being unified among different toolchains -- as very well demonstrated by DWARF<br><br>Comparison with DWARF seems a bit odd here. I agree that unified formats can be useful, but I would point out that there is a great deal of administrative overhead associated with standards like DWARF (committee meetings, heavyweight processes for reaching consensus on new features, release cycles measured in years, etc).  <br><br>Go (for example) uses its own object file format, as opposed to using an existing standard format (e.g. ELF or PE/COFF).  The ability to modify and evolve the object file format is a huge enabler when it comes to rolling out new features.  It was a key element in the last two big Go projects I've worked on; had we been stuck with an existing object file format, the work would have been much more difficult.</div><div style="font-size:small"><br>Than<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 4, 2021 at 10:55 AM Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.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 dir="ltr"><a class="gmail_plusreply" id="m_-7121751841467728202gmail-m_4866271833347366246gmail-m_2172995779967824821plusReplyChip-0" href="mailto:thanm@google.com" target="_blank">+Than McIntosh</a> again to comment on the gc question below.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 4, 2021 at 2:38 AM Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com" target="_blank">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 dir="ltr">Thanks Teresa and others for the clarification!<div><br></div><div>On Fri, Oct 1, 2021 at 8:32 PM Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>> wrote:<br></div></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">I was going to respond similarly, and add a note that it isn't clear that gollvm (LLVM-based Go compiler) supports either PGO or the sanitizers, so that may be more difficult than Rust which does. As Snehasish notes, we are focused on C/C++, but this will all be done in the LLVM IR level and should be language independent in theory.</div></blockquote><div><br></div><div>Let me note that I specifically meant gc (Google's standard Go compiler), not gollvm. IMHO, there is an intrinsic value of data formats being unified among different toolchains -- as very well demonstrated by DWARF.</div><div><br></div><div>(Yes, I'm aware that gc doesn't support even ages-long instruction profiling. One of the reasons is the apparent lack of implemented optimizations that can directly benefit from profiling. In case of memory profiling, the use case is clear. Also, given that BOLT helps Go a lot (up to +20% speed-up on our internal tests), I expect the same for memory profiling, which will warrant extending gc capabilities to use MemProf format.)</div></div></div></blockquote><div><br></div><div>I don't think the gc compiler even involves llvm as it is written in Go. So that's definitely outside the scope of our work. I'm not personally very familiar with Go compiler toolchains and their roadmaps, but Than can probably comment.</div><div><br></div><div>Teresa</div><div><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 class="gmail_quote"><div><br></div><div>Yours,</div><div>Andrey</div><div> </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>Teresa</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 1, 2021 at 10:25 AM Snehasish Kumar <<a href="mailto:snehasishk@google.com" target="_blank">snehasishk@google.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 dir="ltr"><div style="font-size:small">Hi Andrey,</div><div style="font-size:small"><br></div><div style="font-size:small">The serialization format is language independent, though our focus is C/C++. Note that our instrumentation is based on the LLVM sanitizer infrastructure and should work for Rust (supports building with sanitizers [1]). We have not considered using the data profile for non-C/C++ codes.</div><div style="font-size:small"><br></div><div style="font-size:small">Regards,</div><div style="font-size:small">Snehasish</div><div style="font-size:small"><br></div><div style="font-size:small">[1] <a href="https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html" target="_blank">https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 1, 2021 at 9:14 AM Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com" target="_blank">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">Hi Snehasish, David and Theresa,<br>
<br>
I'm really glad to see the steady progress in this area!<br>
<br>
It looks like the format is pretty much language independent<br>
(correct?) -- so it can be applied not only to C/C++, but other<br>
languages (Rust) and even toolchains (Go) as well? If you have already<br>
considered using data profile for non-C/C++, may I kindly ask you to<br>
share your thoughts on this?<br>
<br>
Yours,<br>
Andrey<br>
===<br>
Advanced Software Technology Lab<br>
Huawei<br>
<br>
On Thu, Sep 30, 2021 at 1:17 AM Snehasish Kumar <<a href="mailto:snehasishk@google.com" target="_blank">snehasishk@google.com</a>> wrote:<br>
><br>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"><br></td></tr></tbody></table></span></div></div></div>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"><br></td></tr></tbody></table></span></div></div></div></div>
</blockquote></div>
</blockquote></div></div>