RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v3]

[Yasumasa Suenaga]

On Tue, 9 Sep 2025 13:47:45 GMT, Yasumasa Suenaga <ysuenaga at 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-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga has updated the pull request 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