<div dir="ltr">Hey Kirk,<div><br></div><div>The answer to that is not to use safepoint-biased execution profilers, I think.  </div><div><br></div><div>For Hotspot, profilers can call AsyncGetCallTrace in a signal handler.  That's what we do at Google, and it works just fine (although we keep having to fix AGCT to get decent output).  Sample code: <a href="https://code.google.com/p/lightweight-java-profiler/">https://code.google.com/p/lightweight-java-profiler/</a></div><div><br></div><div>Another thing that users can do on Linux is use perf events, as long as the right agent is in place.  This is somewhat underdocumented, but Stephane Eranian wrote some sample JVMTI code to enable it: <a href="https://lkml.org/lkml/2015/2/10/570">https://lkml.org/lkml/2015/2/10/570</a>  </div><div><br></div><div>We have vague plans to do something with this (although right now the kernel support needed doesn't quite work with our development machines).</div><div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 12:01 AM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk.pepperdine@gmail.com" target="_blank">kirk.pepperdine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Jeremy,<div><br></div><div>Sorry I wasn’t so clear, it’s not about collection, it’s about allocation. In this regard it’s not about about size, it’s about the frequency. People tend allocate small objects frequently and they will avoid allocating large objects frequently. The assumption is, large is expensive but small isn’t. These event will show up using execution profilers but given the safe-point bias of execution profilers and other factors, it’s often clearer to view this problem using memory profilers.</div><div><br></div><div>Kind regards,</div><div>Kirk</div><div><div class="h5"><div><br><div><div>On Jun 25, 2015, at 7:34 PM, Jeremy Manson <<a href="mailto:jeremymanson@google.com" target="_blank">jeremymanson@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Why would allocation frequency be more damaging to performance?  Allocation is cheap, and as long as they become dead before the YG collection, it costs the same to collect one 1MB object as it does to collection 1000 1K objects.<div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 11:54 PM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk.pepperdine@gmail.com" target="_blank">kirk.pepperdine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><p><br></p><p>But, seriously, why didn’t you like my proposal? It can do anything your scheme can with fewer and simpler code changes. The only thing that it cannot do is to sample based on object count (i.e., every 100 objects) instead of based on object size (i.e., every 1MB of allocations). But I think doing sampling based on size is the right approach here (IMHO).</p><div><br></div></div></blockquote><div><br></div></span>I would think that the size based sampling would create a size based bias in your sampling. Since IME, it’s allocation frequency is more damaging to performance, I’d prefer to see time boxed sampling</div><div><br></div><div>Kind regards,</div><div>Kirk Pepperdine</div><div><br></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>