From egahlin at openjdk.org Mon Sep 1 12:00:41 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 1 Sep 2025 12:00:41 GMT Subject: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. Does your change handle logging to a file? I looked into fixing this when I did the initial implementation, but I didn't think it was worth addressing. It only applies to jfr+startup and if the user wants the warning level. If a user doesn't want the message, they can specify jfr+startup=error. Do we log anything with jfr+startup=warning? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3242090448 From jbechberger at openjdk.org Mon Sep 1 12:16:44 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 1 Sep 2025 12:16:44 GMT Subject: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. Without this change, `jfr+startup=warning` doesn't affect the startup logging at all, and it shows the startup message, which was confusing to one of our users (why is it showing `[info]` tagged startup messages when the warning level is set). I'll look into how it handles files later in the day ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3242135188 From jbachorik at openjdk.org Tue Sep 2 08:31:44 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 2 Sep 2025 08:31:44 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v2] In-Reply-To: References:

Message-ID: On Mon, 25 Aug 2025 14:29:08 GMT, Johannes Bechberger wrote: >> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Add queue locking on thread termination src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 185: > 183: } > 184: if (factor > 1) { > 185: u4 new_capacity = capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor; NIT: Could use the MAX2 macro - no real functionality change, though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2315328833 From jbechberger at openjdk.org Tue Sep 2 14:08:25 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 2 Sep 2025 14:08:25 GMT Subject: RFR: 8366486: Test jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out Message-ID: Fix test case by keeping the sampled thread alive long enough. ------------- Commit messages: - Fix issue Changes: https://git.openjdk.org/jdk/pull/27053/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27053&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366486 Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27053.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27053/head:pull/27053 PR: https://git.openjdk.org/jdk/pull/27053 From jbechberger at openjdk.org Tue Sep 2 14:10:49 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 2 Sep 2025 14:10:49 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Sep 2025 08:29:13 GMT, Jaroslav Bachorik wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Add queue locking on thread termination > > src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 185: > >> 183: } >> 184: if (factor > 1) { >> 185: u4 new_capacity = capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor; > > NIT: Could use the MAX2 macro - no real functionality change, though. MIN2 :) I didn't know these macros existed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2316213419 From jbechberger at openjdk.org Wed Sep 3 11:41:32 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 3 Sep 2025 11:41:32 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v3] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add test case and fix bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/97669fe5..cf65d57e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=01-02 Stats: 173 lines in 4 files changed: 172 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From jbechberger at openjdk.org Wed Sep 3 14:22:44 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 3 Sep 2025 14:22:44 GMT Subject: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. Regarding files: `-Xlog:jfr+startup=info:file=a.txt` causes the startup message to be written to the file, but `-Xlog:jfr+startup=warning:file=a.txt` doesn't. So it works both for files and stdout, the implementation changes the behaviour at the root. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3249467266 From egahlin at openjdk.org Wed Sep 3 14:35:53 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 3 Sep 2025 14:35:53 GMT Subject: RFR: 8366809: JFR: Use factory for aggregator functions Message-ID: Could I have a review of a PR that replaces the selection of the aggregator function with a factory, so that the selection only needs to happen once per column instead of for every row? Testing: jdk/jdk/jfr + manual inspection 'jfr view' output Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/27072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366809 Stats: 40 lines in 3 files changed: 10 ins; 2 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/27072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27072/head:pull/27072 PR: https://git.openjdk.org/jdk/pull/27072 From jbechberger at openjdk.org Thu Sep 4 10:17:02 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 4 Sep 2025 10:17:02 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v4] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Improve auto size test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/cf65d57e..57dc56ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=02-03 Stats: 113 lines in 6 files changed: 81 ins; 19 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From jbechberger at openjdk.org Thu Sep 4 10:23:16 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 4 Sep 2025 10:23:16 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v5] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix last commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/57dc56ca..6bd7cd5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=03-04 Stats: 4 lines in 3 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From ysuenaga at openjdk.org Thu Sep 4 11:34:54 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 4 Sep 2025 11:34:54 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU Message-ID: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> 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: (0x6), Model: (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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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: (0x6), Model: (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 From ysuenaga at openjdk.org Thu Sep 4 11:34:54 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 4 Sep 2025 11:34:54 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga wrote: > 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: (0x6), Model: (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 instruc tion, 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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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" ... src/hotspot/cpu/x86/vm_version_x86.cpp line 2581: > 2579: // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least) > 2580: threads_per_package = threads_per_core() * cores_per_cpu(); > 2581: } Check `thread_per_package` from `CPUID` to avoid SIGFPE (div by zero). `CPUID` leaf 0Bh with ECX (subleaf) = 1 seems to return `0` as number of logical processors in spite of leaf 08h is supported in some older processors. It's strange, but I saw it on AMD EPYC 7763 on GitHub Actions runner. The problem appears as following. I haven't faced this problem on AMD Ryzen 3 3300X. # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007f19e11ffeed, pid=11344, tid=11345 # # JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420) # Java VM: OpenJDK 64-Bit Server VM (26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x11ffeed] VM_Version::initialize_cpu_information()+0x2d # # CreateCoredumpOnCrash turned off, no core file dumped # # JFR recording file will be written. Location: /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/scratch/1/hs_err_pid11344.jfr # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/home/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/tmp -ea -esa -XX:-CreateCoredumpOnCrash -Xlog:jfr=trace -XX:StartFlightRecording:filename=./dumped.jfr,dumponexit=true,settings=profile jdk.jfr.startupargs.TestDumpOnExit$TestMain Host: AMD EPYC 7763 64-Core Processor, 4 cores, 15G, Ubuntu 22.04.5 LTS Time: Thu Sep 4 07:17:02 2025 UTC elapsed time: 0.570221 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00007f19d802ad20): JavaThread "main" [_thread_in_vm, id=11345, stack(0x00007f19dff00000,0x00007f19e0000000) (1024K)] Stack: [0x00007f19dff00000,0x00007f19e0000000], sp=0x00007f19dfffbd40, free space=1007k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11ffeed] VM_Version::initialize_cpu_information()+0x2d (vm_version_x86.cpp:2581) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2321741255 From egahlin at openjdk.org Thu Sep 4 14:56:20 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Sep 2025 14:56:20 GMT Subject: RFR: 8366896: JFR: Add gc view support for ZGC Message-ID: Could I have a review of a PR that fixes the 'jfr gc view' when using ZGC? Could I have a review of a PR that fixes the 'jfr gc view' when using ZGC? The problem is that jdk.YoungGarbageCollection and jdk.OldGarbageCollection events are not used with ZGC. Instead, jdk.ZYoungGarbageCollection and jdk.ZOldGarbageCollection are used. Before: **$ jfr view gc recording.jfr** Garbage Collections Start GC ID Type Heap Before GC Heap After GC Longest Pause -------- ----- --------------------- -------------- ------------- ------------- 16:13:43 0 Unknown 868.0 MB 1.6 GB 0.00808 ms 16:13:43 1 Unknown 1.7 GB 3.8 GB 0.00796 ms 16:13:44 2 Unknown 3.8 GB 9.0 GB 0.0136 ms 16:13:45 3 Unknown 6.6 GB 9.0 GB 0.0203 ms 16:13:46 4 Unknown 9.0 GB 9.0 GB 0.00867 ms 16:13:48 5 Unknown 9.0 GB 9.0 GB 0.00775 ms After: **$ jfr view gc recording.jfr** Garbage Collections Start GC ID Type Heap Before GC Heap After GC Longest Pause -------- ----- ---------------------------- -------------- ------------- ------------- 16:13:43 0 ZGC Old Garbage Collection 868.0 MB 1.6 GB 0.00808 ms 16:13:43 1 ZGC Old Garbage Collection 1.7 GB 3.8 GB 0.00796 ms 16:13:44 2 ZGC Old Garbage Collection 3.8 GB 9.0 GB 0.0136 ms 16:13:45 3 ZGC Young Garbage Collection 6.6 GB 9.0 GB 0.0203 ms 16:13:46 4 ZGC Young Garbage Collection 9.0 GB 9.0 GB 0.00867 ms 16:13:48 5 ZGC Young Garbage Collection 9.0 GB 9.0 GB 0.00775 ms Note: "Unknown" can still occur if not all events for a GC ID have been emitted. I also made a change so that GCs are now ordered according to GC ID. This prevents issues where entries with a start time of N/A appear first in cases where not all events are emitted for a GC cycle. Testing: jdk/jdk/jfr + manual inspection with ZGC, G1, Parallel and Serial. Thanks Erik ------------- Commit messages: - Order by GC id - Initial Changes: https://git.openjdk.org/jdk/pull/27099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366896 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27099/head:pull/27099 PR: https://git.openjdk.org/jdk/pull/27099 From egahlin at openjdk.org Thu Sep 4 15:08:46 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Sep 2025 15:08:46 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga wrote: > 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: (0x6), Model: (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 instruc tion, 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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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" ... If a value is missing, emit jmc_undefined_long in event.set_cores(...), so it will show up as N/A in both JMC and the JFR tool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3254159055 From ysuenaga at openjdk.org Fri Sep 5 01:26:25 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 5 Sep 2025 01:26:25 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 15:06:08 GMT, Erik Gahlin wrote: > If a value is missing, emit jmc_undefined_long in event.set_cores(...), so it will show up as N/A in both JMC and the JFR tool. It couldn't for now because `cores` is declared as `uint`. I checked generated code from `metadata.xml`, the field as declared as `uint` (32 bit), so we cannot store `jmc_undefined_long` as `long`. class EventCPUInformation : public JfrEvent { private: const char* _cpu; const char* _description; unsigned _sockets; unsigned _cores; unsigned _hwThreads; But I agree with @egahlin to show up "N/A" in this case. I think it is the most simple way to change data type to `long` for number of CPU cores in `metadata.xml`. Can we do that? I concern the impact for JFR recording data format. As an another option, we can update `EventPrintWriter::getUnsigned` to handle `unsigned int` - it might be reasonable to fix this problem. Which solution is better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3256751516 From jbechberger at openjdk.org Fri Sep 5 08:00:50 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 08:00:50 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v6] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix build on non Linux ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/6bd7cd5c..d67261a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From jbachorik at openjdk.org Fri Sep 5 09:28:13 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Fri, 5 Sep 2025 09:28:13 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v6] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 09:22:02 GMT, Jaroslav Bachorik wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix build on non Linux > > src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 289: > >> 287: return Atomic::load(&_out_of_stack_walking_iterations); >> 288: } >> 289: #endif > > Should this be ASSERT of DEBUG_ONLY? > Eg. the fields are defined via DEBUG_ONLY. Hm, is this because of the definition in whitebox.cpp where we need if/else to return default value if not running with ASSERT ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324573741 From jbechberger at openjdk.org Fri Sep 5 09:28:14 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 09:28:14 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v6] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 09:23:34 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 289: >> >>> 287: return Atomic::load(&_out_of_stack_walking_iterations); >>> 288: } >>> 289: #endif >> >> Should this be ASSERT of DEBUG_ONLY? >> Eg. the fields are defined via DEBUG_ONLY. > > Hm, is this because of the definition in whitebox.cpp where we need if/else to return default value if not running with ASSERT ? Per definition of the macros it's the same ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324574706 From jbechberger at openjdk.org Fri Sep 5 09:28:14 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 09:28:14 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v6] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 09:24:04 GMT, Johannes Bechberger wrote: >> Hm, is this because of the definition in whitebox.cpp where we need if/else to return default value if not running with ASSERT ? > > Per definition of the macros it's the same DEBUG_ONLY is apparently the short version of ?ifdef ASSERT' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324577412 From jbechberger at openjdk.org Fri Sep 5 09:32:16 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 09:32:16 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v6] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 09:25:56 GMT, Jaroslav Bachorik wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix build on non Linux > > test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 86: > >> 84: .sum(); >> 85: ret.add(new LossEvent(actualStart, lostSamples)); >> 86: } > > NIT: This could be probably more efficient by bulding time quantized bucket Sure. But I'm only getting 10 or so events, so I didn't think it would be worth it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324587444 From jbachorik at openjdk.org Fri Sep 5 10:15:32 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Fri, 5 Sep 2025 10:15:32 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v6] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 08:00:50 GMT, Johannes Bechberger wrote: >> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build on non Linux I have a few more minor questions/nits ------------- PR Review: https://git.openjdk.org/jdk/pull/26926#pullrequestreview-3188765342 From jbechberger at openjdk.org Fri Sep 5 10:46:39 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 10:46:39 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v7] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/d67261a7..fa60329a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=05-06 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From jbechberger at openjdk.org Fri Sep 5 11:19:54 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 11:19:54 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v8] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/fa60329a..7e902494 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=06-07 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From jbechberger at openjdk.org Fri Sep 5 11:29:11 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 11:29:11 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v8] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 11:19:54 GMT, Johannes Bechberger wrote: >> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix headers I'm looking forward to your nits :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26926#issuecomment-3258016760 From jbechberger at openjdk.org Fri Sep 5 11:41:29 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 5 Sep 2025 11:41:29 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v9] In-Reply-To: References: Message-ID: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix usage of INCLUDE_JFR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26926/files - new: https://git.openjdk.org/jdk/pull/26926/files/7e902494..cab51632 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926 From egahlin at openjdk.org Mon Sep 8 20:21:48 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 8 Sep 2025 20:21:48 GMT Subject: RFR: 8367107: JFR: Refactor policy tests out of TestRemoteDump Message-ID: Could I get a review of a PR that splits TestRemoteDump.java into two test files? This change prevents timeouts and reduces wall clock time, as the tests can now run in parallel. As part of the change, I am reverting the modification to TestRemoteDump introduced with [JFR: Improve slow tests](https://bugs.openjdk.org/browse/JDK-8364756), which made the test flaky. I also removed unused imports and fixed the incorrect test summary. Testing: 100 * (TestRemoteDump and TestDumpRetention) Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/27153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367107 Stats: 197 lines in 2 files changed: 123 ins; 73 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27153/head:pull/27153 PR: https://git.openjdk.org/jdk/pull/27153 From ysuenaga at openjdk.org Tue Sep 9 08:29:09 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 08:29:09 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: > 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: (0x6), Model: (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 instruc tion, 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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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" ... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use jmc_undefined_long if runs on hybrid CPU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/7ac3885f..2ebbde5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=00-01 Stats: 16 lines in 4 files changed: 7 ins; 4 del; 5 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 From ysuenaga at openjdk.org Tue Sep 9 08:29:10 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 08:29:10 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga wrote: > 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: (0x6), Model: (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 instruc tion, 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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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" ... I updated this patch to set `jmc_undefined_long` if runs on hybrid CPU. It passed jdk_jfr test on my laptop. @egahlin Can you review? You can see `jdk.CPUInformation` event generated on hybrid CPU as following: jdk.CPUInformation { startTime = 16:15:19.185 (2025-09-09) 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: (0x6), Model: (0xb5), Stepping: 0x0 Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 Features: ebx: 0x10800800, 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 = N/A hwThreads = 14 } ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3269483510 From jbachorik at openjdk.org Tue Sep 9 10:07:12 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 9 Sep 2025 10:07:12 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v9] In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 11:41:29 GMT, Johannes Bechberger wrote: >> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix usage of INCLUDE_JFR Marked as reviewed by jbachorik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26926#pullrequestreview-3200624714 From jbachorik at openjdk.org Tue Sep 9 10:12:25 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 9 Sep 2025 10:12:25 GMT Subject: RFR: 8366486: Test jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 14:01:23 GMT, Johannes Bechberger wrote: > Fix test case by keeping the sampled thread alive long enough. Marked as reviewed by jbachorik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27053#pullrequestreview-3200653261 From jbechberger at openjdk.org Tue Sep 9 10:18:53 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 9 Sep 2025 10:18:53 GMT Subject: Integrated: 8366486: Test jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 14:01:23 GMT, Johannes Bechberger wrote: > Fix test case by keeping the sampled thread alive long enough. This pull request has now been integrated. Changeset: 4fc917c2 Author: Johannes Bechberger URL: https://git.openjdk.org/jdk/commit/4fc917c25005d1f88fe43069fe623e243bd022c3 Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod 8366486: Test jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out Reviewed-by: jbachorik ------------- PR: https://git.openjdk.org/jdk/pull/27053 From jbechberger at openjdk.org Tue Sep 9 10:20:02 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 9 Sep 2025 10:20:02 GMT Subject: Integrated: 8366082: Improve queue size computation in CPU-time sampler In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:41:11 GMT, Johannes Bechberger wrote: > Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. This pull request has now been integrated. Changeset: 002f936e Author: Johannes Bechberger URL: https://git.openjdk.org/jdk/commit/002f936ef21943ff1c8c03618091793768e756ac Stats: 299 lines in 7 files changed: 276 ins; 7 del; 16 mod 8366082: Improve queue size computation in CPU-time sampler Reviewed-by: jbachorik ------------- PR: https://git.openjdk.org/jdk/pull/26926 From egahlin at openjdk.org Tue Sep 9 10:34:09 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 9 Sep 2025 10:34:09 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 9 Sep 2025 08:29:09 GMT, Yasumasa Suenaga wrote: >> 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: (0x6), Model: (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 instru ction, 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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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 patc... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Use jmc_undefined_long if runs on hybrid CPU It should not be a problem to change to type long. Values are stored as compressed integers, but you might want to check the event in JMC just to be sure. Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270024207 From ysuenaga at openjdk.org Tue Sep 9 11:04:34 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 11:04:34 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

Message-ID: On Tue, 9 Sep 2025 10:27:22 GMT, Erik Gahlin wrote: > you might want to check the event in JMC just to be sure. I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.

> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270165692 From egahlin at openjdk.org Tue Sep 9 11:35:10 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 9 Sep 2025 11:35:10 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

Message-ID: On Tue, 9 Sep 2025 11:01:32 GMT, Yasumasa Suenaga wrote: > I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. Interesting, it has worked in the past. > I hope the problem would be found by jdk_jfr tests Try to add: + event.getInt("cores"); + Integer value = event.getValue("cores"); to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270271752 From ysuenaga at openjdk.org Tue Sep 9 11:58:56 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 11:58:56 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

Message-ID: On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin wrote: >>> you might want to check the event in JMC just to be sure. >> >> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. >> >>

>> >> >>> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). >> >> I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box. > >> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. > > Interesting, it has worked in the past. > >> I hope the problem would be found by jdk_jfr tests > > Try to add: > > + event.getInt("cores"); > + Integer value = event.getValue("cores"); > > to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value. @egahlin `event.getInt("cores")`: failed java.lang.IllegalArgumentException: Attempt to get field "cores" with illegal data type conversion int at jdk.jfr/jdk.jfr.consumer.RecordedObject.newIllegalArgumentException(RecordedObject.java:890) at jdk.jfr/jdk.jfr.consumer.RecordedObject.getInt(RecordedObject.java:553) at jdk.jfr.event.os.TestCPUInformation.main(TestCPUInformation.java:56) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) `Integer value = event.getValue("cores")`: failed java.lang.ClassCastException: class java.lang.Long cannot be cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in module java.base of loader 'bootstrap') at jdk.jfr.event.os.TestCPUInformation.main(TestCPUInformation.java:57) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270354691 From ysuenaga at openjdk.org Tue Sep 9 13:47:45 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 13:47:45 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v3] In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: > 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: (0x6), Model: (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 instruc tion, 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/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), 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" ... Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into jfr-on-hy-cpu - Use jmc_undefined_long if runs on hybrid CPU - Revert "Update condition" This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420. - Update condition - Add fallback code if logical_cpus == 0 - 8365633: JFR reports incorrect number of cores on hybrid CPU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/2ebbde5f..aeea3fb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=01-02 Stats: 14182 lines in 512 files changed: 6597 ins; 4715 del; 2870 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 From dholmes at openjdk.org Wed Sep 10 06:15:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Sep 2025 06:15:29 GMT Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler [v9] In-Reply-To: References: