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

[John Rose]

This is great stuff.  I am very pleased to think that we can probably simplify the use of the object header for monitors in the directions of CJM and these newer designs.

I enjoyed reading about the two-bit design which avoids touching the global side table on the fast path.  I’m rooting for that.  But still more, I’m rooting for a well-curated set of choices (like theses) which can be configured into Lilliput builds, so that we can test experimentally which work best for varying workloads.

The detection of the condition “recursively locked to self” seems inherently kind of slow when you don’t use the whole header for a pointer.  Am I wrong?

The reason I’m asking about tests for “recursively locked to self” is they are equivalent in power to confinement tests such as we use to enforce temporal bounds in Panama data structures.  The key operations for confinement are (a) acquire confined state or create object initially in such state, (b) verify confined state before access, (c) release confined state.  After that last state, it is often desirable to call libc.free on some memory resource in the object, which in state (b) was being used to contain working data.  Fast (loop-hoistable) temporal confinement checks are the low price we pay for being able to free quickly after last use.

Another reason I like the two-bit design is that it points towards uses of high throughput protection of very small critical sections, with no recursive locking at all.  And my favorite case of that would be atomic access for multi-word structs in Valhalla, when those structs are contained, as mutable variables, in object fields.  Using the object header for some kind of STM seems like a natural move there.  (Not all Valhalla structs will require it atomicity, but some will.)

It would be useful, I think, to evolve these CJM-like structures to support not just classic Java 1.0 synchronization, but also functionally similar use cases, such as enforcement of confinement for Panama capabilities, and enforcement of atomicity for Valhalla structs.

— John

> /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