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

[Yasumasa Suenaga]

On Thu, 2 Oct 2025 05:24:12 GMT, David Holmes <dholmes at 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