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