Low-Overhead Heap Profiling
kirk.pepperdine at gmail.com
Sat Jun 27 10:16:02 UTC 2015
> 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…..
More information about the serviceability-dev