ObjectSynchronizer iterate only in-use monitors?
David Holmes
david.holmes at oracle.com
Tue May 16 06:52:47 UTC 2017
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. :)
> 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