Low-Overhead Heap Profiling

[Jeremy Manson]

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. :)

Jeremy

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

> 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150628/e17276f4/attachment.htm>