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

[Roman Kennke]

Am 18.05.2017 um 10:03 schrieb David Holmes:
> 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).

But Thread::remove() *is* going to block on Threads_lock. If I read the
code correctly, omFlush() is called right after we give up Threads_lock
(thread_main_inner()). Stuff under gListLock in omFlush() is only doing
some simple re-linking of the linked lists. I'll give that a try with
some very careful checking ...

Roman