OM World and Lilliput planning

[Thomas Stüfe]

Hi Coleen,

obsoleting the legacy mode feels a bit risky for an LTS. I am, of course,
happy if the code can be removed.

"and reintroduce (revert) the UseHeavyMonitors option as a develop flag,
rather than a diagnostic flag"

Why not diagnostic?

Cheers, Thomas


On Mon, Jun 17, 2024 at 3:21 PM <coleen.phillimore at oracle.com> wrote:

>
> 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).
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/lilliput-dev/attachments/20240618/821b1d31/attachment-0001.htm>