RFR: 8224816: Provide os::processor_id() implementation for Mac OS
Erik Österlund
erik.osterlund at oracle.com
Wed May 29 13:26:14 UTC 2019
Hi Per,
Thanks for the review.
/Erik
On 2019-05-29 00:53, Per Liden wrote:
> Looks good.
>
> /Per
>
> On 05/28/2019 10:34 AM, Erik Österlund wrote:
>> Hi Per,
>>
>> Thanks for reviewing.
>>
>> On 2019-05-28 09:46, Per Liden wrote:
>>> Hi Erik,
>>>
>>> On 5/27/19 12: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.
>>>> 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/
>>>
>>> Just a few comments:
>>>
>>> * Maybe replace "cpu" with "processor" in variable names, since the
>>> function is named processor_id().
>>
>> Fixed.
>>
>>> * Could we split out the setup of the array into a separate function
>>> helper, like:
>>>
>>> volatile int* mapping = get_apic_to_processor_mapping();
>>
>> Fixed.
>>
>>> * Move the declaration of "apic_to_cpu_mapping" and "next_cpu_id"
>>> out of the function, to avoid the pthread_once initialization checks
>>> every call?
>>
>> Fixed.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~eosterlund/8224816/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8224816/webrev.00_01/
>>
>> Thanks,
>> /Erik
>>
>>> cheers,
>>> /Per
>>>
>>>>
>>>> Thanks,
>>>> /Erik
>>
More information about the hotspot-runtime-dev
mailing list