Integrated: 8320310: CompiledMethod::has_monitors flag can be incorrect

[Jorn Vernee]

On Thu, 23 Nov 2023 15:55:07 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`

This pull request has now been integrated.

Changeset: c8fa3e21
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8fa3e21e6a4fd7846932b545a1748cc1dc6d9f1
Stats:     48 lines in 5 files changed: 9 ins; 17 del; 22 mod

8320310: CompiledMethod::has_monitors flag can be incorrect

Reviewed-by: vlivanov, thartmann

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

PR: https://git.openjdk.org/jdk/pull/16799