3 ms·
Profiling has a lot of its own pitfalls. Use a sampling profiler and your calls to StringBuilder might get compiled so that there are no safepoints inside them
by hyperpape 10y ago
Profiling has a lot of its own pitfalls. Use a sampling profiler and your calls to StringBuilder might get compiled so that there are no safepoints inside them and you never see them[0]. Use instrumentation, and you can massively over weight short methods because of the overhead.
[0] I would think this can realistically happen for StringBuilder calls, but I'm not 100% sure.
- vardump 10y agoI just read this: http://psy-lob-saw.blogspot.com/2015/12/safepoints.html http://psy-lob-saw.blogspot.com/2015/12/safepoints.html Wow, I had no idea how bad sampling profilers are on JVM. And apparently JVM profiling in general. So collecting a stack trace sample requires a thread being suspended at a safepoint. And a global safepoint requires suspending all threads? Sampler that needs to do that will surely not only miss real CPU time consumer but also significantly alter performance behavior. Instrumentation is indeed often a pretty bad option as well. Is it possible to resolve JVM stack traces captured from kernel side (Windows and Linux have mechanisms for this)? That would certainly get around any safepoint restrictions, right?
- hyperpape 10y agoYeah, I think there are ways to get around it, though I'm not super familiar with all of the details. I think that Java Mission Control from Oracle might not have the safepoint bias, and in open source there are also some attempts: https://github.com/RichardWarburton/honest-profiler/wiki https://github.com/RichardWarburton/honest-profiler/wiki.