ObjectSynchronizer iterate only in-use monitors?

David Holmes david.holmes at oracle.com
Wed May 17 02:57:29 UTC 2017


Thanks Dan - my bad again.

David

On 17/05/2017 12:46 AM, Daniel D. Daugherty wrote:
> On 5/16/17 12:52 AM, David Holmes wrote:
>> Correction ...
>>
>> On 16/05/2017 2:49 PM, David Holmes wrote:
>>> On 16/05/2017 12:52 AM, Roman Kennke wrote:
>>>> Am 11.05.2017 um 09:44 schrieb Robbin Ehn:
>>>>> Hi,
>>>>>
>>>>> We have actually been discussing this last few days:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>
>>>> We are seeing the exact same issue as mentioned in the bug report too.
>>>> Sometimes, time-to-safepoint is very high, in the area of ~200ms. The
>>>> reason for this seems to be deflate_idle_monitors().
>>>>
>>>> In the current implementation, the VM thread iterates over all threads,
>>>> and deflates each thread's idle monitors one after another.
>>>>
>>>> I would rather have each Java thread deflate its own idle monitors
>>>> before arriving at a safepoint. This should be much faster because
>>>> higher chances a thread has its own monitors in cache, and deflation
>>>> processing is done in parallel too. This requires some thought... e.g.
>>>> what to do with non-runnable threads.
>>>
>>> This is risky and will need very careful analysis. The
>>> type-stable-memory property of Monitors depends on very careful
>>
>> Monitors don't use TSM - ignore that part. :)
>
> Unless something has changed ObjectMonitor is TSM. Once allocated as an
> ObjectMonitor that memory isn't reused as anything else. So while we
> may deflate an unused ObjectMonitor, it will get added to the free list.
>
> Dan
>
>
>>
>>> synchronization and the fact that deflation only happens at safepoints.
>>
>> This might not be as fragile as I was initially thinking, but a good
>> design walkthrough of Monitor-lifecycle will be essential for
>> understanding any subtleties of existing and proposed approaches.
>>
>> Thanks,
>> David
>>
>>> David
>>> -----
>>>
>>>> If you think that's a good way to go, and don't already have a fix in
>>>> the pipeline, I can take on the bug. I've got synchronizer still hot in
>>>> memory, and experimented with self-processing Java threads before
>>>> safepoint a while back too.
>>>>
>>>> Let me know!
>>>>
>>>> Roman
>>>>
>>>>
>


More information about the hotspot-runtime-dev mailing list