OM World and Lilliput planning

[coleen.phillimore at oracle.com]

On 6/5/24 3:19 AM, Stefan Karlsson wrote:
> 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.

The reason to start with -XX:-UseObjectMonitorTable (off) is to get test 
coverage on that path too, and have time to work out any performance 
issues that we might have before turning it on.

Also, later, step 5. remove UseObjectMonitorTable.  It's a diagnostic 
flag and super-temporary so won't affect applications.

Thanks,
Coleen

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