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

Reply via email to