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