This is the first part of my series; the other parts are
Back to the blog post:
More than three years in the making, with a concerted effort starting last year, my CPU-time profiler landed in Java with OpenJDK 25. It’s an experimental new profiler/method sampler that helps you find performance issues in your code, having distinct advantages over the current sampler. This is what this week’s and next week’s blog posts are all about. This week, I will cover why we need a new profiler and what information it provides; next week, I’ll cover the technical internals that go beyond what’s written in the JEP. I will quote the JEP 509 quite a lot, thanks to Ron Pressler; it reads like a well-written blog post in and of itself.
Before I show you its details, I want to focus on what the current default method profiler in JFR does:
Current JFR Profiling Strategy
JDK 25’s default method profiler also changed, as my previous blog post, Taming the Bias: Unbiased* Safepoint-Based Stack Walking in JFR, described. However, the profiling strategy remained the same.
At every interval, say 10 or 20 milliseconds, five threads running in Java and one in native Java are picked from the list of threads and sampled. This thread list is iterated linearly, and threads not in the requested state are skipped (source).
Problems?
This strategy has problems, as also covered in a talk by Jaroslav Bachorik and me at this year’s FOSDEM:
The aggressive subsampling means that the effective sampling interval depends on the number of cores and the parallelism of your system. Say we have a large machine on which 32 threads can run in parallel. Then JFR on samples at most 19%, turning a sampling rate of 10ms into 53ms. This is an inherent property of wall-clock sampling, as the sampler considers threads on the system. This number can be arbitrarily large, so sub-sampling is necessary.
... continue reading