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

[David Holmes]

On Tue, 7 Oct 2025 18:56:11 GMT, Daniel D. Daugherty <dcubed at 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