RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
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/intel-core-ultra...), 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
On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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
On Thu, 4 Sep 2025 11:29:14 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
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
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 0Bh 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_cp...
Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2396968555
On Thu, 2 Oct 2025 05:24:12 GMT, David Holmes <dholmes@openjdk.org> wrote:
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 0Bh 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=interp...
Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??
I want to use number of logical processors from `CPUID` instruction directly because we can't believe `threads_per_core()` on hybrid CPU. Some of cores (e.g. E cores) might not have hyper threading even though `CPUID` reports HT flag. Thus I think we have to check the value here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2397133449
On Thu, 2 Oct 2025 06:10:05 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??
I want to use number of logical processors from `CPUID` instruction directly because we can't believe `threads_per_core()` on hybrid CPU. Some of cores (e.g. E cores) might not have hyper threading even though `CPUID` reports HT flag. Thus I think we have to check the value here.
Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info. Let me walk through an example to see if I have it right: We have a hybrid system with two sockets, each of which has 6P and 2E cores. Only the P cores have hyper-threading even though the HT bit is set. So the current code would do: _no_of_threads = 28 // I hope that is what the OS reports: 2 * (6*2 + 2) threads_per_core() = 2 // because of HT bit cores_per_cpu() = 8 threads_per_package = 2 * 8 = 16 _no_of_sockets = 28 / 16 = 1 // integer division -> gives wrong answer with new code: threads_per_package = 14 // direct from CPUID logical processors _no_of_sockets = 28 / 14 = 12 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2400974344
On Fri, 3 Oct 2025 06:53:26 GMT, David Holmes <dholmes@openjdk.org> wrote:
Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
Yes, so I think this PR needs reviewer(s) from HotSpot folks.
So the current code would do:
Unfortunately, no. It would derive wrong number of sockets as following: _no_of_threads = 28 // 2 sockets * (6 P-cores * 2 threads + 2 E-cores) threads_per_core() = 2 // HT enabled cores_per_cpu() = 7 // ** different from your thought ** 14 threads per cpu / 2 logical processors threads_per_package = 14 // 2 threads per core * 7 cores per cpu _no_of_sockets = 2 // 28 threads / 14 threads per package `cores_per_cpu()` would return `CPUID` leaf 0Bh for modern Intel CPU as following. According to Software Developer's Manual, leaf 0Bh returns number of "logical" processor in each domains (selected by subleaf (ECX)). if (is_intel()) { bool supports_topology = supports_processor_topology(); if (supports_topology) { result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; } In this PR, all of variables are same with current implementation, thus we can calculate `_no_of_sockets` correctly. But only `threads_per_package` comes from `CPUID`. _no_of_threads = 28 // 2 sockets * (6 P-cores * 2 threads + 2 E-cores) threads_per_core() = 2 // HT enabled cores_per_cpu() = 7 // incorrect, but it would be calculated by values from `CPUID` threads_per_package = 14 // ** different from current implementation ** the value from `CPUID` _no_of_sockets = 2 // 28 threads / 14 threads per package I uploaded test code for `CPUID` leaf 0Bh: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2401759645
On Fri, 3 Oct 2025 12:39:55 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
Let me walk through an example to see if I have it right:
We have a hybrid system with two sockets, each of which has 6P and 2E cores. Only the P cores have hyper-threading even though the HT bit is set. So the current code would do:
_no_of_threads = 28 // I hope that is what the OS reports: 2 * (6*2 + 2) threads_per_core() = 2 // because of HT bit cores_per_cpu() = 8 threads_per_package = 2 * 8 = 16 _no_of_sockets = 28 / 16 = 1 // integer division -> gives wrong answer
with new code:
threads_per_package = 14 // direct from CPUID logical processors _no_of_sockets = 28 / 14 = 12
Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
Yes, so I think this PR needs reviewer(s) from HotSpot folks.
So the current code would do:
Unfortunately, no. It would derive wrong number of sockets as following:
_no_of_threads = 28 // 2 sockets * (6 P-cores * 2 threads + 2 E-cores) threads_per_core() = 2 // HT enabled cores_per_cpu() = 7 // ** different from your thought ** 14 threads per cpu / 2 logical processors threads_per_package = 14 // 2 threads per core * 7 cores per cpu _no_of_sockets = 2 // 28 threads / 14 threads per package
`cores_per_cpu()` would return `CPUID` leaf 0Bh for modern Intel CPU as following. According to Software Developer's Manual, leaf 0Bh returns number of "logical" processor in each domains (selected by subleaf (ECX)).
if (is_intel()) { bool supports_topology = supports_processor_topology(); if (supports_topology) { result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; }
In this PR, all of variables are same with current implementation, thus we can calculate `_no_of_sockets` correctly. But only `threads_per_package` comes from `CPUID`.
_no_of_threads = 28 // 2 sockets * (6 P-cores * 2 threads + 2 E-cores) threads_per_core() = 2 // HT enabled cores_per_cpu() = 7 // incorrect, but it would be calculated by values from `CPUID` threads_per_package = 14 // ** different from current implementation ** the value from `CPUID` _no_of_sockets = 2 // 28 threads / 14 threads per package
I uploaded test code for `CPUID` leaf 0Bh: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-...
Sorry I am very confused as to what is being calculated by what. IIUC (big IF!) we will always calculate `cores_per_cpu` incorrectly because we will assume all cores have the same HT setting - hence when we divide total-threads-per-cpu by threads-per-core, to get cores-per-cpu, the answer may be incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409066160
On Tue, 7 Oct 2025 01:06:31 GMT, David Holmes <dholmes@openjdk.org> wrote:
Okay but this is not a JFR specific change - you are changing these values for all clients of the VM version info.
Yes, so I think this PR needs reviewer(s) from HotSpot folks.
So the current code would do:
Unfortunately, no. It would derive wrong number of sockets as following:
_no_of_threads = 28 // 2 sockets * (6 P-cores * 2 threads + 2 E-cores) threads_per_core() = 2 // HT enabled cores_per_cpu() = 7 // ** different from your thought ** 14 threads per cpu / 2 logical processors threads_per_package = 14 // 2 threads per core * 7 cores per cpu _no_of_sockets = 2 // 28 threads / 14 threads per package
`cores_per_cpu()` would return `CPUID` leaf 0Bh for modern Intel CPU as following. According to Software Developer's Manual, leaf 0Bh returns number of "logical" processor in each domains (selected by subleaf (ECX)).
if (is_intel()) { bool supports_topology = supports_processor_topology(); if (supports_topology) { result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; }
In this PR, all of variables are same with current implementation, thus we can calculate `_no_of_sockets` correctly. But only `threads_per_package` comes from `CPUID`.
_no_of_threads = 28 // 2 sockets * (6 P-cores * 2 threads + 2 E-cores) threads_per_core() = 2 // HT enabled cores_per_cpu() = 7 // incorrect, but it would be calculated by values from `CPUID` threads_per_package = 14 // ** different from current implementation ** the value from `CPUID` _no_of_sockets = 2 // 28 threads / 14 threads per package
I uploaded test code for `CPUID` leaf 0Bh: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-...
Sorry I am very confused as to what is being calculated by what. IIUC (big IF!) we will always calculate `cores_per_cpu` incorrectly because we will assume all cores have the same HT setting - hence when we divide total-threads-per-cpu by threads-per-core, to get cores-per-cpu, the answer may be incorrect.
Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409166531
On Tue, 7 Oct 2025 02:32:08 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
Sorry I am very confused as to what is being calculated by what. IIUC (big IF!) we will always calculate `cores_per_cpu` incorrectly because we will assume all cores have the same HT setting - hence when we divide total-threads-per-cpu by threads-per-core, to get cores-per-cpu, the answer may be incorrect.
Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said.
Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that: int cores_per_cpu() { if (is_hybrid()) { if (hyper_threaded() ) { return _no_of_threads - _no_of_e_cores; } else { return _no_of_threads; } } else { return _no_of_threads / threads_per_core(); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409331900
On Tue, 7 Oct 2025 04:44:24 GMT, David Holmes <dholmes@openjdk.org> wrote:
Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said.
Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that:
int cores_per_cpu() { if (is_hybrid()) { if (hyper_threaded() ) { return _no_of_threads - _no_of_e_cores; } else { return _no_of_threads; } } else { return _no_of_threads / threads_per_core(); } }
I think it is difficult for the following reasons: 1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-... 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409430996
On Tue, 7 Oct 2025 05:43:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that:
int cores_per_cpu() { if (is_hybrid()) { if (hyper_threaded() ) { return _no_of_threads - _no_of_e_cores; } else { return _no_of_threads; } } else { return _no_of_threads / threads_per_core(); } }
I think it is difficult for the following reasons:
1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-... 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future.
Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query. I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway. So where does this leave us? - `cores_per_cpu` is an approximation - anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409613404
On Tue, 7 Oct 2025 07:07:51 GMT, David Holmes <dholmes@openjdk.org> wrote:
I think it is difficult for the following reasons:
1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-... 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future.
Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.
I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.
So where does this leave us? - `cores_per_cpu` is an approximation - anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation
Based on the comments that I'm reading in this PR, it seems like the existing logic presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing (AMP) or is the AMP support in a different place in the code. A very long time ago, Solaris SPARC servers could be provisioned with differing processors with different core counts and speed ratings. I don't know if we supported those AMP servers in Java or not, but there was definitely support in Solaris itself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2411598511
On Tue, 7 Oct 2025 18:56:11 GMT, Daniel D. Daugherty <dcubed@openjdk.org> wrote:
Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.
I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.
So where does this leave us? - `cores_per_cpu` is an approximation - anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation
Based on the comments that I'm reading in this PR, it seems like the existing logic presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing (AMP) or is the AMP support in a different place in the code.
A very long time ago, Solaris SPARC servers could be provisioned with differing processors with different core counts and speed ratings. I don't know if we supported those AMP servers in Java or not, but there was definitely support in Solaris itself.
I updated this PR to revert data type change to `uint`, so number of cores might be incorrect on hybrid CPU. "cores" in `jdk.CPUInformation` event would be set "approximated" value, but "Hybrid Architecture" would be added into "description" field in that case. I grep'ed to find user of `cores_per_cpu`, this value would be used in JFR and reporting only like I've fixed in #26808 , thus this change affects limited area only AFAICS.
Based on the comments that I'm reading in this PR, it seems like the existing logic presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing (AMP) or is the AMP support in a different place in the code.
Has Intel released AMP processor for Xeon / Core line? If AMP is SPARC only in context of Java, it would be implemented on SPARC-specific code, but it has already gone... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412215707
On Tue, 7 Oct 2025 18:56:11 GMT, Daniel D. Daugherty <dcubed@openjdk.org> wrote:
Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query.
I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway.
So where does this leave us? - `cores_per_cpu` is an approximation - anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation
Based on the comments that I'm reading in this PR, it seems like the existing logic presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing (AMP) or is the AMP support in a different place in the code.
A very long time ago, Solaris SPARC servers could be provisioned with differing processors with different core counts and speed ratings. I don't know if we supported those AMP servers in Java or not, but there was definitely support in Solaris itself.
@dcubed-ojdk my recollection is that the "symmetry" in SMP related to memory accesses - but there are differing definitions. There is also a presumption that all "logical processors" behave effectively the same, and for multi-socket systems all CPU's are the same. That is still true-enough with these Hybrid chips, they just don't have the same internal topology so we can't coarsely assume we can calculate things like "number of cores" by knowing number-of-threads and whether hyper-threading is enabled. Unfortunately you also cannot easily get the exact details of that topology. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412394944
On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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
On Thu, 4 Sep 2025 15:06:08 GMT, Erik Gahlin <egahlin@openjdk.org> 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`. <Field type="uint" name="cores" label="Cores" /> 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<EventCPUInformation> { 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
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 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...), 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
On Tue, 9 Sep 2025 08:29:09 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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
On Tue, 9 Sep 2025 10:27:22 GMT, Erik Gahlin <egahlin@openjdk.org> 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. <img width="812" height="340" alt="image" src="https://github.com/user-attachments/assets/1919ac46-77c5-4658-8fa1-8aea7aa6b..." />
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
On Tue, 9 Sep 2025 11:01:32 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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
On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin <egahlin@openjdk.org> 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.
<img width="812" height="340" alt="image" src="https://github.com/user-attachments/assets/1919ac46-77c5-4658-8fa1-8aea7aa6b..." />
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
On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin <egahlin@openjdk.org> 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.
<img width="812" height="340" alt="image" src="https://github.com/user-attachments/assets/1919ac46-77c5-4658-8fa1-8aea7aa6b..." />
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 Could you review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3296425149
On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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: <unknown> (0x6), Model: <unknown> (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
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 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...), 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
On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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 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
Can someone review this PR? I think I have to got reviewers both HotSpot and JFR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3358971095
On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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 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
I'm not sure promoting the value to a long is a good idea anymore, but I'm not completely against it either. Maybe it's sufficient to update the description of the cores field and say the value may be incorrect if there is hybrid cores? Maybe there should be a field indicating hybrid cores, or maybe we should do something else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359374252
On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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 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
I saw similar behavior in `VM.info` dcmd, and I modified the output for CPU information in #26808 - removed thread-related information, and added "hybrid" flag. But I think we cannot apply similar method in JFR because we have to treat number of cores even if "hybrid" flag would be added in event definition, and also we might change all of viewer (JMC, jfr command, and more) to hide number of cores if hybrid flag is set. It is impractical I think. So I think it is the most reasonable to set `min_jlong` which already means "N/A". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359516888
On Thu, 2 Oct 2025 07:12:49 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
So I think it is the most reasonable to set `min_jlong` which already means "N/A".
I don't think using the min_jlong value is the problem, we do that for other event values, but promoting the field to a long value might be too disruptive. It's a value users are likely to extract programmatically. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359711876
On Thu, 2 Oct 2025 07:58:08 GMT, Erik Gahlin <egahlin@openjdk.org> wrote:
but promoting the field to a long value might be too disruptive. It's a value users are likely to extract programmatically.
If the data size is important than showing "N/A", I think we can set "0" for number of cores as I proposed [at first](https://openjdk.github.io/cr/?repo=jdk&pr=27080&range=00). But you said before that it should not be a problem to change to type long: https://github.com/openjdk/jdk/pull/27080#issuecomment-3270024207 Which is better? I think it is better not to change data size rather than showing "N/A" for compatibility. I think it is whether it feels natural for JFR that "0" means "N/A". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3359903487
On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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 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
But you said before that it should not be a problem to change to type long: [#27080 (comment)](https://github.com/openjdk/jdk/pull/27080#issuecomment-3270024207)
I looked at it from a file format perspective (varint encoding), but from an API perspective, as you showed, both getInt("cores") and getValue("cores") may throw an exception. This could impact users who have no problem with hybrid cores today. Also, their code may work on a development or test machine but then break on production hardware. jcmd is meant for humans to read, so a change there has less impact. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3360138311
On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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 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
So should I revert the change to original? I think it is better not to change data type. Compatibility should prefer than user friendly message ("N/A") in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3360629462
On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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 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
src/hotspot/cpu/x86/vm_version_x86.cpp line 2595:
2593: // estimate the number of cores. 2594: // -1 if hybrid CPU because it is difficult to derive number of cores. 2595: _no_of_cores = supports_hybrid() ? -1 : (cores_per_cpu() * _no_of_sockets);
It is only meant to be an estimate and -1 is not an estimate at all it is a "I don't know" answer. But why do we not know - using my earlier example won't number of cores be 8 as expected 6P+2E? Even if not it would yield a better approximation than -1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2400979011
On Fri, 3 Oct 2025 06:55:56 GMT, David Holmes <dholmes@openjdk.org> wrote:
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
src/hotspot/cpu/x86/vm_version_x86.cpp line 2595:
2593: // estimate the number of cores. 2594: // -1 if hybrid CPU because it is difficult to derive number of cores. 2595: _no_of_cores = supports_hybrid() ? -1 : (cores_per_cpu() * _no_of_sockets);
It is only meant to be an estimate and -1 is not an estimate at all it is a "I don't know" answer. But why do we not know - using my earlier example won't number of cores be 8 as expected 6P+2E? Even if not it would yield a better approximation than -1.
I think incorrect value is not useful because it causes confusing. If we have to keep current code to set estimated value, I can use `VM_Version::supports_hybrid()` in JFR code to emit -1 on the event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2401819924
On Fri, 3 Oct 2025 12:56:59 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
src/hotspot/cpu/x86/vm_version_x86.cpp line 2595:
2593: // estimate the number of cores. 2594: // -1 if hybrid CPU because it is difficult to derive number of cores. 2595: _no_of_cores = supports_hybrid() ? -1 : (cores_per_cpu() * _no_of_sockets);
It is only meant to be an estimate and -1 is not an estimate at all it is a "I don't know" answer. But why do we not know - using my earlier example won't number of cores be 8 as expected 6P+2E? Even if not it would yield a better approximation than -1.
I think incorrect value is not useful because it causes confusing.
If we have to keep current code to set estimated value, I can use `VM_Version::supports_hybrid()` in JFR code to emit -1 on the event.
Even if the value is incorrect, it still has some value as an approximation. We could update the description to make this clearer, or perhaps provide additional information to help users. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2401874712
On Fri, 3 Oct 2025 13:15:03 GMT, Erik Gahlin <egahlin@openjdk.org> wrote:
I think incorrect value is not useful because it causes confusing.
If we have to keep current code to set estimated value, I can use `VM_Version::supports_hybrid()` in JFR code to emit -1 on the event.
Even if the value is incorrect, it still has some value as an approximation. We could update the description to make this clearer, or perhaps provide additional information to help users.
This PR adds "Hybrid Architecture" to the description field. Do you think it is enough only it? I think it is better to add some notice that number of cores is approximate value, and it might be incorrect on hybrid CPU. However I have no idea where to add it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2403620724
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 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...), 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 three additional commits since the last revision: - Fix comment line - Fix comments - Revert "Use jmc_undefined_long if runs on hybrid CPU" This reverts commit 2ebbde5f963eec47b8709afd68f45cb169b096a8. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/aeea3fb0..d7b2edd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=02-03 Stats: 18 lines in 4 files changed: 4 ins; 8 del; 6 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
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 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...), 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: Fix build error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/d7b2edd0..a0520474 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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
On Tue, 7 Oct 2025 14:04:46 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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:
Fix build error
src/hotspot/cpu/x86/vm_version_x86.cpp line 2579:
2577: if (threads_per_package == 0) { 2578: // Fallback code to avoid div by zero in subsequent code. 2579: // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)
Can we assert that this is not a hybrid CPU? src/hotspot/share/jfr/metadata/metadata.xml line 855:
853: 854: <Event name="CPUInformation" category="Operating System, Processor" label="CPU Information" 855: description="Characteristics and descriptions of the processor(s) the JVM is running on. Note that "cores" field would be incorrect on hybrid CPU."
Perhaps better stated on the cores field: <Field type="uint" name="cores" label="Cores (approximation on a hybrid CPU" /> ? But really this is for JFR folk to decide. Do these labels get used for GUI tools like JMC? BTW I assume that "hwThreads" is the number of logical processors - right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412407479 PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412412315
On Wed, 8 Oct 2025 03:25:52 GMT, David Holmes <dholmes@openjdk.org> wrote:
Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
Fix build error
src/hotspot/cpu/x86/vm_version_x86.cpp line 2579:
2577: if (threads_per_package == 0) { 2578: // Fallback code to avoid div by zero in subsequent code. 2579: // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)
Can we assert that this is not a hybrid CPU?
Maybe yes. I checked `CPUID` 0Bh subleaf 1 on both Core Ultra 5 135U and 225U, they reports correct number of logical processors. However I cannot check all of hybrid CPUs and I'm not sure all of them should return correct value at here. Thus I'm not sure we can add `assert` here for hybrid CPU.
BTW I assume that "hwThreads" is the number of logical processors - right?
Yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412657326 PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412657709
On Wed, 8 Oct 2025 06:14:03 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
src/hotspot/share/jfr/metadata/metadata.xml line 855:
853: 854: <Event name="CPUInformation" category="Operating System, Processor" label="CPU Information" 855: description="Characteristics and descriptions of the processor(s) the JVM is running on. Note that "cores" field would be incorrect on hybrid CPU."
Perhaps better stated on the cores field:
<Field type="uint" name="cores" label="Cores (approximation on a hybrid CPU" />
? But really this is for JFR folk to decide. Do these labels get used for GUI tools like JMC?
BTW I assume that "hwThreads" is the number of logical processors - right?
BTW I assume that "hwThreads" is the number of logical processors - right?
Yes
Perhaps better stated on the cores field:
Thanks for your comment! I added that sentence to `description` attribute in `Field` element. After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip) $ jfr metadata --events jdk.CPUInformation /tmp/test.jfr @Name("jdk.CPUInformation") @Category({"Operating System", "Processor"}) @Label("CPU Information") @Description("Characteristics and descriptions of the processor(s) the JVM is running on") class CPUInformation extends jdk.jfr.Event { @Label("Start Time") @Timestamp("TICKS") long startTime; @Label("Type") String cpu; @Label("Description") String description; @Unsigned @Label("Sockets") int sockets; @Unsigned @Label("Cores") @Description("Approximation on a hybrid CPU") int cores; @Unsigned @Label("Hardware Threads") int hwThreads; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412763021
On Wed, 8 Oct 2025 06:50:27 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> wrote:
BTW I assume that "hwThreads" is the number of logical processors - right?
Yes
Perhaps better stated on the cores field:
Thanks for your comment! I added that sentence to `description` attribute in `Field` element. After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip)
$ jfr metadata --events jdk.CPUInformation /tmp/test.jfr @Name("jdk.CPUInformation") @Category({"Operating System", "Processor"}) @Label("CPU Information") @Description("Characteristics and descriptions of the processor(s) the JVM is running on") class CPUInformation extends jdk.jfr.Event { @Label("Start Time") @Timestamp("TICKS") long startTime;
@Label("Type") String cpu;
@Label("Description") String description;
@Unsigned @Label("Sockets") int sockets;
@Unsigned @Label("Cores") @Description("Approximation on a hybrid CPU") int cores;
@Unsigned @Label("Hardware Threads") int hwThreads; }
Metadata looks good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412915309
On Wed, 8 Oct 2025 07:50:47 GMT, Erik Gahlin <egahlin@openjdk.org> wrote:
Perhaps better stated on the cores field:
Thanks for your comment! I added that sentence to `description` attribute in `Field` element. After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip)
$ jfr metadata --events jdk.CPUInformation /tmp/test.jfr @Name("jdk.CPUInformation") @Category({"Operating System", "Processor"}) @Label("CPU Information") @Description("Characteristics and descriptions of the processor(s) the JVM is running on") class CPUInformation extends jdk.jfr.Event { @Label("Start Time") @Timestamp("TICKS") long startTime;
@Label("Type") String cpu;
@Label("Description") String description;
@Unsigned @Label("Sockets") int sockets;
@Unsigned @Label("Cores") @Description("Approximation on a hybrid CPU") int cores;
@Unsigned @Label("Hardware Threads") int hwThreads; }
Metadata looks good
@egahlin Can you approve this PR? Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2413260517
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 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...), 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: Update metadata.xml ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/a0520474..126feb9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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
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 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...), 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: Add description attribute to Field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/126feb9d..a9dbfb99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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
On Wed, 8 Oct 2025 06:53:26 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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:
Add description attribute to Field
If @egahlin is happy with the JFR side then nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27080#pullrequestreview-3313499645
On Wed, 8 Oct 2025 06:53:26 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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:
Add description attribute to Field
Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27080#pullrequestreview-3320902481
On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga@openjdk.org> 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: <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 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...), 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" ...
This pull request has now been integrated. Changeset: be107224 Author: Yasumasa Suenaga <ysuenaga@openjdk.org> URL: https://git.openjdk.org/jdk/commit/be10722436f20df26de66c00c4bc1b6772aa9087 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod 8366847: JFR reports incorrect number of cores on hybrid CPU Reviewed-by: dholmes, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/27080
participants (4)
-
Daniel D. Daugherty
-
David Holmes
-
Erik Gahlin
-
Yasumasa Suenaga