Sharing the markword (aka Valhalla's markword use)

[John Rose]

On 11 Mar 2024, at 5:41, Kennke, Roman wrote:
>
> Can value objects be locked? If not, could value objects use the same bits that are used for locking of identity objects?

Fair question.  NO, a larval object is never visible outside the thread which created it, so there is no need to lock.  The blanket rule is that value objects (in larval or adult state) are NEVER locked, and the JVM can throw an exception if somebody tries to lock one.

(There are minor exceptions to the rule about visibility of larvae, but they don’t relate to locking.  The GC needs to look at larvae from its worker threads.  So the GC might needs to distinguish the states with care.  But of course the GC doesn’t perform object locking.  A debugger might ask JVMTI to peek inside a thread, and might even try to call a toString method on objects it sees in there.  We will need some special-casing there to prevent larvae from escaping by that route.)

> Other than that, it should be easy to preserve larvae bit across GC, pretty much like lock-bits.

That would be perfect, IMO.

And if the GC ever does identity-shifting optimizations on values, it can consult those saved larval-bits to get the optimizations.

Full disclosure:  The GC does NOT do such things today, AFAIK.  The JIT’s deoptimization logic DOES create new value identities from debug info, when non-allocated objects must be allocated along slow paths.  In that case, the larval bit might be significant even today.  In any case, good JVM architecture not only supports the optimizations we do today, but anticipates a reasonable range of future optimizations.  Designing such a “future-proof” architecture is inherently difficult and fallible, but IMO it has been one of Java’s distinctive strengths.

For the other points, it looks like we are on the same page.  Thanks for the responses, Roman.