RFR: 8320310: CompiledMethod::has_monitors flag can be incorrect [v4]

[Jorn Vernee]

On Mon, 11 Dec 2023 18:38:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently, the `CompiledMethod::has_monitors` flag is set when either a `monitorenter` is parsed by C1, and `monitorexit` is parsed by C1 or C2 during method compilation. However, not necessarily every bytecode of a method is parsed, which means that we could miss all `monitorenter`/`monitorexit` byte codes in a method, while it actually does use monitors. This can lead to situations where a thread holds a monitor, but `has_monitors` for all frames is set to `false`, leading to an assertion failure in 'freeze_internal' in continuationFreezeThaw.cpp:
>> 
>>     assert(monitors_on_stack(current) == ((current->held_monitor_count() - current->jni_monitor_count()) > 0),
>>          "Held monitor count and locks on stack invariant: " INT64_FORMAT " JNI: " INT64_FORMAT, (int64_t)current->held_monitor_count(), (int64_t)current->jni_monitor_count());
>> 
>> The proposed fix is to rely on `Method::has_monitor_bytecodes` to set the `has_monitors` flag when compiling, which is immune to issues where not all byte codes of a method are parsed during compilation. We can follow the pattern established for `has_reserved_stack_access`, which is similar.
>> 
>> Note that this PR is based on: https://github.com/openjdk/jdk/pull/16416 which disables the assertion. The goal of this PR is to fix the issue, and then re-enable the assertion.
>> 
>> Testing: Tier 1-4, `java/lang/Thread/virtual/stress/PinALot.java`
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-enable assert again

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/16799#issuecomment-1881031735