RFR (jdk10): JDK-8180175: ObjectSynchronizer only needs to iterate in-use monitors

David Holmes david.holmes at oracle.com
Thu May 18 08:03:15 UTC 2017


On 18/05/2017 5:54 PM, Roman Kennke wrote:
> Am 18.05.2017 um 04:07 schrieb David Holmes:
>> Roman,
>>
>> I just pushed this but now I think there is a problem with this
>> optimization.
>>
>> When a thread terminates, omFlush is used to transfer the thread's
>> inUseList to the global inUseList. This happens after the thread has
>> been removed from the _threads_list and can run concurrently with a
>> safepoint. This means that there is a window of time where the
>> monitors in the thread's inUseList will not be seen by the safepoint
>> oops_do processing:
>> - the thread oops_do won't be called because the thread is not in the
>> thread's list
>> - the monitors are not yet in the global in-use-list
>>
>> Did I overlook something?
>
> Ugh. How ugly :-)
>
> Is there a reason why omFlush cannot be called from the same block where
> the thread is removed from _thread_list, under the Threads_lock ?

I think the explicit intent is to let it run independent of safepoints 
(which holding the Threads_lock would affect). I guess it depends how 
long it takes to run in general ... and we'd need to check that the code 
executed while holding the gListLock is truly leaf code.

David

> I need to think about this a little more...
>
> Roman
>


More information about the hotspot-runtime-dev mailing list