[openjdk/lilliput] Rendezvous GC threads under STS for monitor deflation (PR #27)

[Roman Kennke]

Hi Dave,

I'm taking this discussion onto the mailing list, and keep out GH 
notifications :-)

I read the paper once in full, but I still need to digest it a little 
more. Just some comments from my perspective:

1. I have implemented a prototype for compact hashcode which only 
requires 2 bits in the object header. The idea is to recompute hashcode 
as long as an object doesn't move, and as soon as a hashed object is 
moved (by the GC), the hashcode will be 'appended' to the copied object 
(which sometimes makes the object larger - in many cases the hashcode 
fits into alignment gap, though).

2. The main trouble that I have with the current locking scheme is 
caused by stack-locks ('thin locks'). It is inherently racy to get hold 
of a mark-word that is displaced by a stack-lock by a 'foreign' thread. 
Full inflated object monitors are less problematic: once inflated, it is 
safe (with caveats, see https://github.com/openjdk/lilliput/pull/27) to 
access the displaced mark word concurrently. That is why I am currently 
working on a way to disable stack-locking altogether, and need only deal 
with full monitors. It looks to me that in this regard, your proposed 
CJM is similar to current object monitors. Is that correct?

I will study CJM in more detail and probably will have more questions. :-)

Thanks for your input!!

Cheers,
Roman

> /Mailing list message from Dave Dice <mailto:dave.dice at oracle.com> on 
> lilliput-dev <mailto:lilliput-dev at mail.openjdk.java.net>:/
> 
> Abstract : In the context of project Lilliput, which attempts to reduce 
> the size of object header in the HotSpot Java Virtual Machine (JVM), we 
> explore a curated set of synchronization algorithms. Each of the 
> algorithms could serve as a potential replacement implementation for the 
> ?synchronized? construct in HotSpot. Collectively, the algorithms 
> illuminate trade-offs in space-time properties.
> 
> The key design decisions are where to locate synchronization metadata 
> (monitor fields), how to map from an object to those fields, and the 
> lifecycle of the monitor information.
> 
> The readers is assumed to be familiar with current HotSpot 
> implementation of ?synchronized? as well as the Compact Java Monitors 
> (CJM) design (https://arxiv.org/abs/2102.04188)
> 
> Dave
> 
> p.s.,
> 
> Don?t expect any surprises regarding performance ? common sense and 
> intuition prevail. As you?d expect, the more involved ?synchronized" is 
> with the header word, the more performance we can squeeze out, albeit at 
> a cost in complexity.
> 
> Note that I narrowed the space of solutions to cover only those that 
> avoid the need for deferred deflation, as monitor accretion and 
> deflation policies remain a continuing problem in HotSpot.
> 
> Finally, for reference, performance data is included for pthread_mutex 
> operations and ReentrantLock.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/lilliput/pull/27#issuecomment-963500322>, or 
> unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AAIEKHPJKWSQSRL2ZBZ7YDDULAQGDANCNFSM5GYGJIAA>.
>