OM World and Lilliput planning

[coleen.phillimore at oracle.com]

Hi Roman, Thomas and Aleksey,

I filed an RFE for the first part of this. 
https://bugs.openjdk.org/browse/JDK-8334299 and will be working on a 
CSR.  I feel like we're backtracking a bit from what we did in JDK 22/23 
but this seems better to me.  Comments?

Thanks,
Coleen

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