Low-Overhead Heap Profiling

Jeremy Manson jeremymanson at google.com
Sun Jun 28 16:32:16 UTC 2015

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 code.google.com before the turndown. :)


On Sat, Jun 27, 2015 at 3:16 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com>

> Hi Jeremy,
> >
> > The answer to that is not to use safepoint-biased execution profilers, I
> think.
> 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.
> 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.
> 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…..
> Kind regards,
> Kirk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150628/e17276f4/attachment.html>

More information about the serviceability-dev mailing list