The build/test tool `ProfileResults` that aggregates JFRs and prints the hot stacks doesn't work with new CPUTime profiler in Java 25

[mikemccand]

Java 25 added a new CPUTime profiler which uses Linux kernel APIs to sample threads every N CPU instructions instead of every X msec wall-clock time. This eliminates silly ghosts like threads listening forever on a socket. It sounds really cool. Wow, it uses JEP 518 -- look how hard it is to eliminate/reduce safepoint bias!

I switched nightly benchy to CPU time profiler, but it produces vacuous reports, clearly missing all the meat. See mikemccand/luceneutil#562 for specifics.

I think it's because ProfileResults tool doesn't know about the new jdk.CPUTimeSample event -- the fix should be simple, in the isInteresting method. I'll try to make a PR soon.

[mikemccand]

Is there any way to remove that Description header (from the issue template chosen when I pick the type of issue I'm opening)? I always go and edit my comment to remove it after ... seems obvious that the op is the description of the issue heh.

[mikemccand]

Also, if CPUTime profiler works well for nightly benchy, we could also switch Lucene's tests profiler to it too? Is there a tests profiler....? I just assume there is, since we have ProfileResults!

[rmuir]

good find, I think you are correct: we should be able to switch to this new event, and remove the hacks in isInteresting?

I think isInteresting() was born to try to workaround the problem solved here, otherwise the gradle epoll thread would always show up on top...