RFR: 8315884: New Object to ObjectMonitor mapping [v3]

Coleen Phillimore coleenp at openjdk.org
Thu Jul 11 13:11:04 UTC 2024


On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1830:
>> 
>>> 1828:     FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT);
>>> 1829:     warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT");
>>> 1830:   }
>> 
>> Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT?
>
> Maybe. It boils down to what to do when the JVM receives `-XX:LockingMode={LM_LEGACY,LM_MONITOR} -XX:+UseObjectMonitorTable` 
> The options I see are
> 1. Select `LockingMode=LM_LIGHTWEIGHT`
> 2. Select `UseObjectMonitorTable=false`
> 3. Do not start the VM
> 
> Between 1. and 2. it is impossible to know what the real intentions were. But with being a newer `-XX:+UseObjectMonitorTable` it somehow seems more likely.
> 
> Option 3. is probably the sensible solution, but it is hard to determine. We tend to not close the VM because of incompatible options, rather fix them. But I believe there are precedence for both. If we do this however we will have to figure out all the interactions with our testing framework. And probably add some safeguards.

UseObjectMonitorTable is a Diagnostic option and LockingMode is (Deprecated) but a full-fledged product option, so I think the product option should override.  So I pick 2.  They might have changed to Legacy to compare performance or something like that, and missed that the table is only for lightweight locking when switching the command line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673989707


More information about the serviceability-dev mailing list