RFR (S) 8250589: Move Universe::_reference_pending_list into OopHandle
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Jul 28 11:26:11 UTC 2020
Thanks David,
Coleen
On 7/27/20 7:06 PM, David Holmes wrote:
> On 28/07/2020 12:10 am, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 7/27/20 9:24 AM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> On 27/07/2020 11:05 pm, coleen.phillimore at oracle.com wrote:
>>>> Summary: Use synchronization to reference the
>>>> _reference_pending_list with OopHandle
>>>
>>> Why isn't ownership of the Heap_lock sufficient for the
>>> synchronization any more?
>>
>> Multiple GC threads synchronize on this value, when one holds the
>> Heap_lock:
>>
>> // Reference pending list manipulation. Access is protected by
>> // Heap_lock. The getter, setter and predicate require the caller
>> // owns the lock. Swap is used by parallel non-concurrent reference
>> // processing threads, where some higher level controller owns
>> // Heap_lock, so requires the lock is locked, but not necessarily by
>> // the current thread.
>>
>> The comment is in the header file, explaining this.
>
> Sorry I completely fixated on the lock assertion and missed the fact
> the current code still does Atomic::xchg. The new code just
> internalises that in the OopHandle logic. (that will teach me to take
> too quick a look late at night)
>
> Kim and Aleksey already pointed out the only things I was going to
> point out.
>
> Looks good.
>
> Thanks,
> David
>
>> Thanks,
>> Coleen
>>
>>>
>>> Thanks,
>>> David
>>>
>>> (and apologies as I'm done for the day so won't see your response
>>> till morning.)
>>>
>>>> Tested with tier1-6 with 100% passed (no other existing test
>>>> failures!)
>>>>
>>>> open webrev at
>>>> http://cr.openjdk.java.net/~coleenp/2020/8250589.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250589
>>>>
>>>> Thanks,
>>>> Coleen
>>
More information about the hotspot-dev
mailing list