ObjectSynchronizer iterate only in-use monitors?

Carsten Varming varming at gmail.com
Tue May 16 12:54:27 UTC 2017


Dear Roman,

Give it a go.

Carsten

On Tue, May 16, 2017 at 8:53 AM, Roman Kennke <rkennke at redhat.com> wrote:

> 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/
>
> On Tue, May 16, 2017 at 6:32 AM, Roman Kennke <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
>>
>>
>
>


More information about the hotspot-runtime-dev mailing list