RFR: 8298371: monitors_on_stack extracts unprocessed oops

[Robbin Ehn]

On Thu, 8 Dec 2022 10:27:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While investigating JDK-8298058 we've found that monitors_on_stack extracts oops without setting up the RegisterMap to process oops. This then leaks out stale oops.
> 
> A simple fix is to change the RegisterMap to perform oops processing. However, monitors_on_stack is only used in an assert, so this means that we'll get a difference in behavior between release builds and debug builds. This has the potential to hide bugs in debug builds. It has been suggested to me that it might be better to simply remove the assert:
> 
>   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 suggested patch just turns on processing, but I'm also fine with removing the assert if that seems to be a better solution.
> 
> Tested with reproducer using Fuzz.java + ZGC

Marked as reviewed by rehn (Reviewer).

Monitor counting is always on, regardless of review enabled or not.
The loom asserts says that if we find a monitor on stack we must have a count of non-jni monitor.
But may have a monitor count even if there is none on stack.

I don't see this assert covering more cases than the assert in JavaThread::exit(). (which always checked, regardless of review enabled or not)

So I really think we can remove this assert.

But if you just want to fix the bug that is fine.

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

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