Support jdk.CPUTimeSample event in ProfileResults for Java 25+ (JEP 509) by iprithv · Pull Request #15983 · apache/lucene

iprithv · 2026-04-24T21:58:49Z

Description

Java 25 added CPU-time profiling (JEP 509) which emits jdk.CPUTimeSample
events. ProfileResults did not recognize this event type, causing empty
profiling reports when the CPU-time profiler is active.

Resolves #15926

…+ (JEP 509)

mikemccand

Whoa, thank you for picking this up @iprithv -- I left some comments about maybe being less lenient about two sampling methods used a the same time.

mikemccand · 2026-04-27T11:47:34Z

+          // needed. When available, we skip legacy execution samples to avoid double-counting.
+          return name.equals("jdk.CPUTimeSample");
+        }
        return (name.equals("jdk.ExecutionSample") || name.equals("jdk.NativeMethodSample"))


I think NativeMethodSample is also a dup, if CPUTime and wall-clock sampling are both enabled?

Yes, I expanded the comment to say that explicitly so it matches the code. Thanks!

mikemccand · 2026-04-27T11:49:02Z

    <setting name="period">1 ms</setting>
  </event>

+  <event name="jdk.CPUTimeSample">


Could we turn off the old (wall-clock) sampling (jdk.ExecutionSample, jdk.NativeMethodSample) and just fully commit to CPUTime. In nightly benchmarks we've found the 1 msec sampling to add non-trivial overhead (I think ~5-7% slower).

The 1msec sampling was necessary for tests in order to find places wasting CPU. most tests just don't run that long.

Done,

Added gradle/testing/profiling.linux.jfc: legacy samplers off, jdk.CPUTimeSample on with a 1 ms throttle so short chunks still get dense enough samples.

Left gradle/testing/profiling.jfc for non-Linux with 1 ms ExecutionSample / NativeMethodSample.

CodeProfilingPlugin loads the Linux file when os.name contains linux, otherwise profiling.jfc.

Thanks both!

mikemccand · 2026-04-27T11:50:26Z

+
+    // Pre-scan to detect if CPU-time samples (Java 25+, JEP 509) are available.
+    // If so, prefer them over legacy execution samples to avoid double-counting.
+    boolean hasCPUTimeSamples = "cpu".equals(mode) && detectCPUTimeSamples(files);


Could we make this stricter? Throw an exception if we see a mix of CPUTime and legacy events? Lucene (and in general anyone profiling, hmm except maybe profiler debuggers heh) should only have one sampler enabled at a time?

I initially added the strict mixed-sampler check here, but removed it after @rmuir follow up review since the two Lucene JFC files are now mutually exclusive.

So the exclusivity now lives in the selected JFC config instead of a pre-scan in ProfileResults. Thanks!

rmuir · 2026-04-27T20:18:03Z

+   * Pre-scan recording files to detect if any jdk.CPUTimeSample events are present. When they are,
+   * we prefer them over legacy jdk.ExecutionSample/jdk.NativeMethodSample to avoid double-counting.
+   */
+  static boolean detectCPUTimeSamples(List<String> files) throws IOException {


Instead of this logic, should we just have profiling.linux.jfc that is loaded for linux, and profiling.jfc used for others?

Yes, done. Linux uses gradle/testing/profiling.linux.jfc, everyone else gradle/testing/profiling.jfc, selected in CodeProfilingPlugin from the host OS. Thanks!

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

rmuir · 2026-04-27T21:41:33Z

    String name = event.getEventType().getName();
    switch (mode) {
      case "cpu":
+        if (hasCPUTimeSamples) {


I don't think we need this boolean parameter nor the if block.

Just something like:

return name.equals("jdk.CPUTimeSample") || name.equals("jdk.ExecutionSample") || name.equals("jdk.NativeMethodSample");

sure, updated. thanks!

rmuir · 2026-04-27T21:42:51Z

 <!--
-Collects only execution and method samples at a low interval
+  Wall-clock execution samples for CPU profiling on platforms where JEP 509 CPU-time sampling
+  is unavailable (non-Linux). On Linux, CodeProfilingPlugin uses profiling.linux.jfc instead.


I don't see a profiling.linux.jfc in your PR

my bad, missed it in adding in previous commit. Thanks!

rmuir · 2026-04-27T21:43:44Z

+   * wall-clock samples ({@code jdk.ExecutionSample} / {@code jdk.NativeMethodSample}); only one
+   * CPU sampler should be enabled in JFR settings.
+   */
+  static boolean resolveCpuTimeSampling(List<String> files) throws IOException {


Remove the whole function as the two files are mutually exclusive. This is very verbose and not needed.

sure, done. thanks!

rmuir · 2026-04-27T21:43:54Z

    }
+
+    // Pre-scan recordings: decide CPU-time vs legacy sampling and reject mixed configurations.
+    boolean hasCPUTimeSamples = "cpu".equals(mode) && resolveCpuTimeSampling(files);


nuke this one too

sure, removed this too. thanks!

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

mikemccand

Thank you for the all the iterations @iprithv -- I think this is close!

mikemccand · 2026-04-28T13:31:50Z

+  /**
+   * JEP 509 CPU-time sampling ({@code jdk.CPUTimeSample}) is implemented on Linux. Use a Linux-only
+   * JFR template with CPU-time sampling only; other hosts keep wall-clock execution sampling for
+   * short tests.


Wait, it's for all tests, not just short tests right? Maybe just remove for short tests?

Sure, done. Updated. Thanks!

mikemccand · 2026-04-28T13:32:54Z

      Provider<Boolean> frametypesOption) {}
+
+  /**
+   * JEP 509 CPU-time sampling ({@code jdk.CPUTimeSample}) is implemented on Linux. Use a Linux-only


Maybe is currently (Java 25) implemented only on Linux, so we use a Linux-only JFR template...?

yes, updated. Thanks!

mikemccand · 2026-04-28T13:33:38Z

+   */
+  private static String profilingSettingsPath() {
+    String os = System.getProperty("os.name", "").toLowerCase(Locale.ROOT);
+    return os.contains("linux") ? "testing/profiling.linux.jfc" : "testing/profiling.jfc";


Actually, instead of baking linux in the name, could we use cputime? Maybe in the future other OS's can support CPU time sampling too...

Sure, makes sense. Thanks!

mikemccand · 2026-04-28T13:35:30Z

+-->
+<configuration version="2.0" label="TestProfilingLinux" description="CPU-time sampling for unit tests (Linux)" provider="Apache">
+  <event name="jdk.ExecutionSample">
+    <setting name="enabled">false</setting>


Oh, are these events enabled by default, so we have to have these entries (jdk.ExecutionSample and jdk.NativeMethodSample) to explicitly then disable them?

i think you are correct, I don't believe it is strictly necessary to have them in this file with enabled: false.

removed the explicit disabled entries. The CPU time template now only enables jdk.CPUTimeSample plus the allocation events used by heap profiling. Thanks!

mikemccand · 2026-04-28T13:37:59Z


 Build
 ---------------------
+* GITHUB#15926: Support jdk.CPUTimeSample event (Java 25+, JEP 509) in ProfileResults.


Can we word a bit more user-friendly-y? Maybe Use the new (Java 25+, JEP 509) CPU time sampling profiler when available (currently just on Linux), and fall back to the legacy wall-clock...?

sure, done. thanks!

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

mikemccand

Looks great! I'll merge & backport! Thank you @iprithv and @rmuir.

This should also fix mikemccand/luceneutil#562, so we can finally see CPUTime profiler JFRs from nightly benchy and on blunders.io! (Oooh I think blunders.io flame charts are already working w/ CPUTime sampling).

mikemccand · 2026-04-29T17:06:47Z

Hmm, there is some pre-existing issue that causes gradle not to print the JFR stack traces. Instead it says this:

> Task :showJfrProfileSummary
One of the test tasks failed, skipping.

Yet tests were successful, nothing seems to have failed.

This is what I'm running:

./gradlew -p lucene/core test -Ptests.profile=true -Ptests.profile.stacksize=8 -Ptests.profile.linenumbers=true

Somehow in CodeProfilingPlugin.java this part is false(?)-failing:

        if (getShouldRunConditions().get().stream().anyMatch(value -> value == false)) {
          getLogger().lifecycle("One of the test tasks failed, skipping.");
          return;
        }

I haven't debugged any further yet ... if I disable that check then I get some profiler output but I don't think it's counting CPUTime events ... not sure:

Aggregated summary of 1 jfr profile.
PROFILE SUMMARY from 105485 events (total: 105485)
  tests.profile.mode=cpu
  tests.profile.count=10
  tests.profile.stacksize=8
  tests.profile.linenumbers=true
PERCENT       CPU SAMPLES   STACK
0.47%         498           sun.nio.ch.UnixFileDispatcherImpl#pread0() [Native code]
                              at sun.nio.ch.UnixFileDispatcherImpl#pread():57 [JIT compiled code]
                              at sun.nio.ch.IOUtil#readIntoNativeBuffer():339 [JIT compiled code]
                              at sun.nio.ch.IOUtil#read():307 [JIT compiled code]
                              at sun.nio.ch.IOUtil#read():284 [Inlined code]
                              at sun.nio.ch.FileChannelImpl#readInternal():1198 [JIT compiled code]
                              at sun.nio.ch.FileChannelImpl#implRead():1170 [JIT compiled code]
                              at sun.nio.ch.FileChannelImpl#read():1152 [JIT compiled code]
0.25%         265           org.apache.lucene.util.ByteBlockPool$DirectTrackingAllocator#getByteBlock():97 [JIT compiled cod\
e]
                              at org.apache.lucene.util.ByteBlockPool#nextBuffer():196 [JIT compiled code]
                              at org.apache.lucene.index.TermsHashPerField#initStreamSlices():161 [JIT compiled code]
                              at org.apache.lucene.index.TermsHashPerField#add():139 [Inlined code]
                              at org.apache.lucene.index.TermsHashPerField#add():207 [JIT compiled code]
                              at org.apache.lucene.index.IndexingChain$PerField#invertTokenStream():1365 [JIT compiled code]
                              at org.apache.lucene.index.IndexingChain$PerField#invert():1256 [JIT compiled code]
                              at org.apache.lucene.index.IndexingChain#processField():773 [JIT compiled code]

I'm also baffled by the total event count (105485) ... it doesn't match what jfr summary says for jdk.CPUTimeSample:

base) raptorlake:trunk[main]$ jfr summary ./lucene/core/build/tests-cwd/hotspot-pid-3877240-id-1-2026_04_29_12_55_47.jfr

 Version: 2.1
 Chunks: 7
 Start: 2026-04-29 16:53:42 (UTC)
 Duration: 125 s

 Event Type                              Count  Size (bytes)
=============================================================
 jdk.ObjectAllocationInNewTLAB          164932       3167800
 jdk.CPUTimeSample                      111550       1964718
 jdk.ObjectAllocationOutsideTLAB         22485        386121
 org.junit.TestExecution                  8673        671942
 jdk.Checkpoint                           7698      81389727

iprithv · 2026-04-29T17:49:24Z

@mikemccand getDidWork() was the wrong check here. It can be false for skipped/up-to-date/not-selected test tasks even when nothing failed. I changed this to check task.getState().getFailure() == null instead here

On the count mismatch, I think ProfileResults is counting CPUTime samples that have a non-null stack trace, while jfr summary counts all jdk.CPUTimeSample events. The JFR summary has no ExecutionSample / NativeMethodSample, so this output should be coming from CPUTime.

iprithv added 2 commits April 25, 2026 03:17

GITHUB#15926: Support jdk.CPUTimeSample in ProfileResults for Java 25…

78af0c1

…+ (JEP 509)

Merge branch 'main' into fix/profile-results-cputime-sample

f952eb7

github-actions Bot added the module:build-infra label Apr 24, 2026

github-actions Bot added this to the 11.0.0 milestone Apr 24, 2026

Updated CHANGES.txt

254196d

mikemccand reviewed Apr 27, 2026

View reviewed changes

rmuir reviewed Apr 27, 2026

View reviewed changes

iprithv added 2 commits April 28, 2026 02:44

review changes

5125d0e

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

Merge branch 'main' into fix/profile-results-cputime-sample

ed3c9bf

iprithv requested review from mikemccand and rmuir April 27, 2026 21:30

rmuir reviewed Apr 27, 2026

View reviewed changes

review changes

d076437

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

iprithv requested a review from rmuir April 28, 2026 06:49

rmuir approved these changes Apr 28, 2026

View reviewed changes

mikemccand reviewed Apr 28, 2026

View reviewed changes

iprithv added 3 commits April 28, 2026 20:03

review changes

30d4510

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

Merge branch 'main' into fix/profile-results-cputime-sample

0d78f10

review changes

6f2c12f

Signed-off-by: prithvi <prithvisivasankar@gmail.com>

iprithv requested a review from mikemccand April 28, 2026 14:49

Merge branch 'main' into fix/profile-results-cputime-sample

0e18580

mikemccand approved these changes Apr 29, 2026

View reviewed changes

mikemccand merged commit dd94a52 into apache:main Apr 29, 2026
13 checks passed

iprithv mentioned this pull request Apr 29, 2026

Fix JFR profile summary skip check #15997

Open

Conversation

iprithv commented Apr 24, 2026

Description

Uh oh!

mikemccand left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikemccand left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikemccand left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mikemccand commented Apr 29, 2026

Uh oh!

iprithv commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development