RFR: 8224816: Provide os::processor_id() implementation for Mac OS

Erik Österlund erik.osterlund at oracle.com
Wed May 29 13:30:27 UTC 2019


Hi David,

On 2019-05-29 12:02, David Holmes wrote:
> Hi Erik,
>
> On 27/05/2019 8:05 pm, Erik Österlund wrote:
>> Hi,
>>
>> In order to port ZGC to Mac OS, we need to implement 
>> os::processor_id(), due to the use of CPU locals in ZGC.
>> I built an implementation that uses CPUID to get the APIC id, and 
>> from that determine a unique CPU id.
>> Note though that the APIC ids are split over a potentially larger 
>> number space than the number of processors.
>> In order to reliably translate APIC ids to CPU ids, I first use CPUID 
>> to query how many bits are being used
>> for APIC ids, and then create an array of integers covering that 
>> space. The array maps possible APIC id positions
>> to a unique processor id. The array is lazily populated with APIC id 
>> -> processor id mappings.
>
> So you aren't actually querying a processor id as such but rather 
> creating a mapping from APIC ID to [0, num_processors). This processor 
> id may be quite different to what the OS might consider the "processor 
> id" - right?

Yes, that's right.

> It's a shame this stuff is so painful. We have a number of uses of 
> cpuid to try and query topology information (some of which is 
> incorrect - see JDK-8219434) and it is all nearly unfathomable code to 
> understand and thus debug.

Yeah, the complexity of doing something so simple is unfortunate indeed. :/

/Erik

> Cheers,
> David
>
>> The specific CPUID leaf used to query this topology information is 
>> intel-specific, but that should be okay as all macs are Intel based.
>> I have tried this out on a number of macs with a mac port of ZGC (to 
>> be upstreamed soon), and it worked well.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8224816
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8224816/webrev.00/
>>
>> Thanks,
>> /Erik



More information about the hotspot-runtime-dev mailing list