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 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 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 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 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.

@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 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 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 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 Could you review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3296425149

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 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 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

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 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 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 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 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 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