ObjectSynchronizer iterate only in-use monitors?

[Roman Kennke]

I'd be interested in giving it a spin with Shenandoah. I might even hack
up MonitorInUseLists support. Would you be ok with me taking the patch
and doing some modifications to it, and maybe pushing it to the
Shenandoah repo?

Instead of hooking up to the Service thread, I'd hook it up to GC
scheduler thread (G1 and Shenandoah only). This way we'd ensure that
monitors have been deflated when we get to marking the roots, which
considerably shortens the respective pauses.

Roman

Am 16.05.2017 um 13:37 schrieb Carsten Varming:
> FYI. Last year I wrote a small patch[1] against JDK9 that enables
> monitor deflation to happen outside a safepoint. There was little
> interest then, so I never proposed it as a patch. The JDK9 code has
> moved on a little bit, so the patch probably doesn't apply cleanly,
> but the patch shows one way to complete the life of a monitor without
> going through a safepoint.
>
> Carsten
>
> [1] http://cr.openjdk.java.net/~cvarming/monitor_deflate_conc/0/
> <http://cr.openjdk.java.net/%7Ecvarming/monitor_deflate_conc/0/>
>
> On Tue, May 16, 2017 at 6:32 AM, Roman Kennke <rkennke at redhat.com
> <mailto:rkennke at redhat.com>> wrote:
>
>     Am 16.05.2017 um 11:48 schrieb Robbin Ehn:
>     > Correction,
>     >
>     > On 05/16/2017 11:45 AM, Robbin Ehn wrote:
>     >> Yes, but since we are at a safepoint you should be able to use gc
>     >> worker in that case also?
>     >
>     > or the java thread. And scratch 'also' :)
>
>     This clearly requires co-operation from the GC.
>
>     Also, I noticed that some GCs cannot do deflation during root
>     scanning,
>     because they stow away mark words during marking, and temporarily
>     store
>     forwarding pointers into the mark words, and only restore mark words
>     after GC. This obviously conflicts with monitor deflation. Which means
>     we need some GC cooperation there too... I will figure something out.
>
>     Roman
>
>