OM World and Lilliput planning

[Stefan Karlsson]

Hi Coleen,

Thanks for moving the "OM World" towards completion. I have one comment 
below:

On 2024-06-04 22:52, coleen.phillimore at oracle.com wrote:
>
> 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.

What is the benefit of starting with this turned off and then a few 
weeks later making it default? I think we'll get better functional test 
coverage if it is enabled by default. We had a very similar situation 
when Lightweight locking was turned off by default and many bugs weren't 
found until it was turned on by default.

Thanks,
StefanK

>
> 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).
>