<div dir="ltr">I'm glad to see Richard's Honest Profiler, because it looks like he cadged my sample code and made a real profiler out of it.  It means I may not have to migrate my sample code from <a href="http://code.google.com">code.google.com</a> before the turndown. :)<div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 27, 2015 at 3:16 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">Hi Jeremy,<br>
<span class=""><br>
><br>
> The answer to that is not to use safepoint-biased execution profilers, I think.<br>
<br>
</span>Thank you for the advice. I’ve been advocating for a number of years that people understand the sampling bias that exists in all profilers. I also would consider safe point bias being the most egregious form or sampling possible. This is why I’m very happy to see Richard’s Honest profiler (using AsyncGetCallTrace) show up and also to have inspired Pierre Laporte to start work on a lock profiler project at our (un)conference (jCrete). As an aside, we hope jCrete can help inspire and support more efforts like this.<br>
<br>
My desire here is to ensure that minimize the effects of sample bias on the results. In this regards, I like the approach you are proposing. My concern with Tony’s approach what that it would introduce a size based sampling bias. As I mentioned before, GC costs is one thing to consider however I’m more concerned with frequency related allocation costs and it’s effect on application throughputs.<br>
<br>
Also, I think we have other techniques that can infer where an allocation has taken place be it in a tlab or even in tenured. I’m not sure that we have to profile for this type of information though if we can get it for almost free…..<br>
<br>
Kind regards,<br>
Kirk<br>
<br>
</blockquote></div><br></div>