<div dir="ltr"><div>Hi Coleen,</div><div><br></div><div>obsoleting the legacy mode feels a bit risky for an LTS. I am, of course, happy if the code can be removed.</div><div><br></div><div>"and reintroduce (revert) the UseHeavyMonitors option as a develop flag, rather than a diagnostic flag"</div><div><br></div><div>Why not diagnostic? <br></div><div><br></div><div>Cheers, Thomas<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 17, 2024 at 3:21 PM <<a href="mailto:coleen.phillimore@oracle.com">coleen.phillimore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi Roman, Thomas and Aleksey,<br>
<br>
I filed an RFE for the first part of this. <br>
<a href="https://bugs.openjdk.org/browse/JDK-8334299" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8334299</a> and will be working on a <br>
CSR.  I feel like we're backtracking a bit from what we did in JDK 22/23 <br>
but this seems better to me.  Comments?<br>
<br>
Thanks,<br>
Coleen<br>
<br>
On 6/5/24 3:19 AM, Stefan Karlsson wrote:<br>
> Hi Coleen,<br>
><br>
> Thanks for moving the "OM World" towards completion. I have one <br>
> comment below:<br>
><br>
> On 2024-06-04 22:52, <a href="mailto:coleen.phillimore@oracle.com" target="_blank">coleen.phillimore@oracle.com</a> wrote:<br>
>><br>
>> Hi, This is what I wrote up after an internal discussion.  I am about <br>
>> to file some RFEs/CSRs (or maybe will next week).  Let me know what <br>
>> you think.<br>
>><br>
>> Thanks,<br>
>> Coleen<br>
>><br>
>> What we call OM World is saving the ObjectMonitor in a <br>
>> ConcurrentHashTable rather than in the markWord of the Java Object. <br>
>> Lilliput absolutely requires this since for Lilliput the Klass <br>
>> pointer is also in the markWord and to get to the Klass pointer for a <br>
>> locked object, the code would have to go to the displaced header in <br>
>> unboundedly racy situations.<br>
>><br>
>> Without Lilliput, this is also helpful in that it frees up markWord <br>
>> bits for concurrent GCs or Valhalla  to use. Because of this, and <br>
>> because of the high level of testing this type of change requires, <br>
>> we'd like to push this change to mainline ahead of the Lilliput work.<br>
>><br>
>> OM World is built on top of Lightweight locking as Lightweight <br>
>> locking is required (doesn't save the stack location in the markWord <br>
>> as does Legacy locking).  To reduce the maintenance burden and <br>
>> potential tricky interactions between new features and Legacy <br>
>> locking, we'd like to deprecate Legacy locking in JDK 24.<br>
>><br>
>> Deprecating Legacy locking then makes the flag LockingMode not make <br>
>> any sense, as one of three enumerations will be missing. Also, to <br>
>> introduce OM World on top of Lightweight locking, it would be good to <br>
>> have that on a diagnostic flag in case of customer performance <br>
>> issues.  It doesn't make sense to have a new locking mode for OM <br>
>> World, since it shares 80% code with Lightweight locking.<br>
>><br>
>> Therefore I (with input from Axel and Stefan) propose the following <br>
>> for JDK 24:<br>
>><br>
>> 1. Reintroduce the flag UseHeavyMonitors for LockingMode=LM_MONITOR<br>
>> 2. Deprecate LockingMode=LM_LEGACY<br>
>> 3. Deprecate the flag LockingMode.  It's a new flag, legacy code <br>
>> won't miss it.<br>
>> 4. When OM World is ready to integrate, introduce a new diagnostic <br>
>> flag UseObjectMonitorTable<br>
>>       - Start default off<br>
>>       - Make it default on midway through JDK 24 if no problems.<br>
><br>
> What is the benefit of starting with this turned off and then a few <br>
> weeks later making it default? I think we'll get better functional <br>
> test coverage if it is enabled by default. We had a very similar <br>
> situation when Lightweight locking was turned off by default and many <br>
> bugs weren't found until it was turned on by default.<br>
><br>
> Thanks,<br>
> StefanK<br>
><br>
>><br>
>> JDK 25:<br>
>><br>
>> 1. Obsolete Legacy locking mode (removes the code - TBD)<br>
>> 2. Obsolete LockingMode flag<br>
>> 3. We can hold onto UseObjectMonitorTable for a while (off turns off <br>
>> Lilliput UseCompactObjectHeaders).<br>
>><br>
><br>
<br>
</blockquote></div>