ObjectSynchronizer iterate only in-use monitors?

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue May 16 14:46:32 UTC 2017


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