September 2025 - hotspot-jfr-dev

RFR: 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally
by Chihiro Ito 27 Oct '25

27 Oct '25

Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams. Tests updated to validate lifecycle consistency: Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream. Test: jdk/jdk/jfr ------------- Commit messages: - 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally Changes: https://git.openjdk.org/jdk/pull/26710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365066 Stats: 648 lines in 7 files changed: 584 ins; 30 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/26710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26710/head:pull/26710 PR: https://git.openjdk.org/jdk/pull/26710

4 9

RFR: 8366240: Improve memory ordering in new CPU Time Profiler
by Johannes Bechberger 25 Oct '25

25 Oct '25

Remove acq-rel semantics where it isn't needed. ------------- Commit messages: - Remove unnecessary line - Remove redundant synchronization Changes: https://git.openjdk.org/jdk/pull/26960/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26960&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366240 Stats: 34 lines in 2 files changed: 5 ins; 9 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/26960.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26960/head:pull/26960 PR: https://git.openjdk.org/jdk/pull/26960

5 12

RFR: 8356968: JFR: Compilation event should be enabled for all compilations by default
by Aleksey Shipilev 22 Oct '25

22 Oct '25

In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high. Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0. See more logs in the bug itself. Additional testing: - [x] Ad-hoc tests with printing compilation events - [x] Linux x86_64 server fastdebug, `jdk_jfr` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/25247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356968 Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25247/head:pull/25247 PR: https://git.openjdk.org/jdk/pull/25247

3 8

RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
by Yasumasa Suenaga 10 Oct '25

10 Oct '25

On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. $ jfr print --events jdk.CPUInformation test.jfr jdk.CPUInformation { startTime = 10:49:27.692 (2025-09-04) cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0 Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" sockets = 1 cores = 7 hwThreads = 14 } Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/inte…, it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. This patch sets `0` to `cores` and "Hybrid Architecture" is added to `description` as following if `jdk.CPUInformation` is generated on hybrid CPU. I want to set `-1` to `cores` TBH, but I didn't because `cores` is declared as `uint` - `-1` is equivalent with `UINT_MAX`, it looks like strange at here. jdk.CPUInformation { startTime = 10:48:12.420 (2025-09-04) cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0 Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 Features: ebx: 0x42800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC, Hybrid Architecture" sockets = 1 cores = 0 hwThreads = 14 } This change affects showing information only, would not change the behavior like active processor count. ------------- Commit messages: - Revert "Update condition" - Update condition - Add fallback code if logical_cpus == 0 - 8365633: JFR reports incorrect number of cores on hybrid CPU Changes: https://git.openjdk.org/jdk/pull/27080/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366847 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27080.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080 PR: https://git.openjdk.org/jdk/pull/27080

4 46

Re: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9]
by Johannes Bechberger 03 Oct '25

03 Oct '25

On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue Andrei has already reviewed. Maybe @jbachorik could rereview it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3351139204

2 1

RFR: 8368809: JFR: Remove events from testSettingConfiguration in TestActiveSettingEvent
by Erik Gahlin 30 Sep '25

30 Sep '25

Could I have a review of a PR that removes an old test hack that is no longer needed. Testing: jdk/jfr/event/runtime/TestActiveSettingEvent.java Thanks Erik ------------- Commit messages: - Add missing s - Improve formatting - Initial Changes: https://git.openjdk.org/jdk/pull/27565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27565&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368809 Stats: 27 lines in 1 file changed: 4 ins; 22 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27565/head:pull/27565 PR: https://git.openjdk.org/jdk/pull/27565

2 2

RFR: 8368563: JFR: Improve jfr query help text
by Erik Gahlin 30 Sep '25

30 Sep '25

Could I have review of PR that improves the help text for `jfr query`? Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Fix alignment - Initial Changes: https://git.openjdk.org/jdk/pull/27558/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27558&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368563 Stats: 18 lines in 2 files changed: 2 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27558.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27558/head:pull/27558 PR: https://git.openjdk.org/jdk/pull/27558

2 2

RFR: 8367953: JFR sampler threads does not appear in thread dump
by Yasumasa Suenaga 30 Sep '25

30 Sep '25

I tried to get thread dump of the process which is enabled JFR, then I got strange thread dump like this: os_prio=0 cpu=64.47ms elapsed=20.34s tid=0x00007ff7cd3ffae0 nid=59812 runnable os_prio=0 cpu=12.76ms elapsed=20.34s tid=0x00007ff7cd3ff5a0 nid=59811 runnable Thread name is lacked in the dump (and lacks of LF in addition). I checked them with `ps -eL -o pid,tid,comm`, then I was aware they were JFR sampler threads. 59789 59811 JFR CPU Sampler 59789 59812 JFR Sampler Thr So they should be shown like this: "JFR Sampler Thread" os_prio=0 cpu=25.59ms elapsed=8.77s tid=0x00007f5f45626a50 nid=62979 runnable "JFR CPU Sampler Thread" os_prio=0 cpu=4.78ms elapsed=8.78s tid=0x00007f5f45626060 nid=62978 runnable They are implemented in `JfrSamplerThread` and `JfrCPUSamplerThread`, extends `NonJavaThread`. They do not have `print_on()`, so `Thread::print_on()` would be used - it would not print thread name. Other child class of `NonJavaThread` like `WatcherThread` overrides `print_on` to show thread name. Thus both of JFR sampler threads should do so. ------------- Commit messages: - Remove override qualifier - 8367953: JFR sampler threads does not appear in thread dump Changes: https://git.openjdk.org/jdk/pull/27357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367953 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27357/head:pull/27357 PR: https://git.openjdk.org/jdk/pull/27357

2 3

RFR: 8362573: Incorrect weight of the first ObjectAllocationSample JFR event (regression)
by Markus Grönlund 30 Sep '25

30 Sep '25

Greetings, Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled. The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads. This time also includes a regression test. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8362573 Changes: https://git.openjdk.org/jdk/pull/26900/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26900&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362573 Stats: 194 lines in 7 files changed: 133 ins; 30 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/26900.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26900/head:pull/26900 PR: https://git.openjdk.org/jdk/pull/26900

2 6

Re: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9]
by Erik Gahlin 30 Sep '25

30 Sep '25

On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue Thanks for adding vm.flagless. The other changes are better reviewed by those more familiar with the code introduced in JEP 509. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3350952789

1 0