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

[Daniel D. Daugherty]

On Tue, 7 Oct 2025 07:07:51 GMT, David Holmes <dholmes at 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-check.c
>> 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