OM World and Lilliput planning

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Tue Jun 4 20:52:49 UTC 2024


Hi, This is what I wrote up after an internal discussion.  I am about to 
file some RFEs/CSRs (or maybe will next week).  Let me know what you think.

Thanks,
Coleen

What we call OM World is saving the ObjectMonitor in a 
ConcurrentHashTable rather than in the markWord of the Java Object. 
Lilliput absolutely requires this since for Lilliput the Klass pointer 
is also in the markWord and to get to the Klass pointer for a locked 
object, the code would have to go to the displaced header in unboundedly 
racy situations.

Without Lilliput, this is also helpful in that it frees up markWord bits 
for concurrent GCs or Valhalla  to use. Because of this, and because of 
the high level of testing this type of change requires, we'd like to 
push this change to mainline ahead of the Lilliput work.

OM World is built on top of Lightweight locking as Lightweight locking 
is required (doesn't save the stack location in the markWord as does 
Legacy locking).  To reduce the maintenance burden and potential tricky 
interactions between new features and Legacy locking, we'd like to 
deprecate Legacy locking in JDK 24.

Deprecating Legacy locking then makes the flag LockingMode not make any 
sense, as one of three enumerations will be missing.  Also, to introduce 
OM World on top of Lightweight locking, it would be good to have that on 
a diagnostic flag in case of customer performance issues.  It doesn't 
make sense to have a new locking mode for OM World, since it shares 80% 
code with Lightweight locking.

Therefore I (with input from Axel and Stefan) propose the following for 
JDK 24:

1. Reintroduce the flag UseHeavyMonitors for LockingMode=LM_MONITOR
2. Deprecate LockingMode=LM_LEGACY
3. Deprecate the flag LockingMode.  It's a new flag, legacy code won't 
miss it.
4. When OM World is ready to integrate, introduce a new diagnostic flag 
UseObjectMonitorTable
       - Start default off
       - Make it default on midway through JDK 24 if no problems.

JDK 25:

1. Obsolete Legacy locking mode (removes the code - TBD)
2. Obsolete LockingMode flag
3. We can hold onto UseObjectMonitorTable for a while (off turns off 
Lilliput UseCompactObjectHeaders).



More information about the lilliput-dev mailing list