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

[David Holmes]

On Thu, 4 Sep 2025 11:29:14 GMT, Yasumasa Suenaga <ysuenaga at 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