On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas <abold...@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
