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

[David Holmes]

Hi Roman,

Yes a new bug must be filed for this.

Sorry I didn't catch it before the push.

Thanks,
David

On 18/05/2017 7:57 PM, Roman Kennke wrote:
> Am 18.05.2017 um 11:00 schrieb Robbin Ehn:
>> Hi,
>>
>> On 05/18/2017 10:10 AM, David Holmes wrote:
>>> On 18/05/2017 6:08 PM, Roman Kennke wrote:
>>>> 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?
>>
>> Good catch!
>>
>>>>>>
>>>>>> 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 ?
>>
>> Couldn't omFlush be done before Threads_lock in Thread::remove, while
>> the thread is still on threads list?
>> I do not see the reason why you want to hold the Threads_lock? To me
>> it looks like gListLock is enough?
>
> I was thinking the same. Currently testing this.
>
> I suppose a new bug needs to be filed for this?
>
> Roman
>