RFR: 8297389: resexhausted003 fails with assert(!thread->owns_locks()) failed: must release all locks when leaving VM [v2]

[Tobias Hartmann]

On Tue, 29 Nov 2022 01:01:02 GMT, Dean Long <dlong at openjdk.org> wrote:

> I'm not sure if it's guaranteed that replay runs single-threaded. I haven't looked into the details, but I think ReplayInline can run in any compiler thread after startup, and then of course there is JDK-8254110.

But ReplayInline does not load ciMethodData, i.e., does not call `process_ciMethodData`, right?

The only way this code can get executed is through `JNI_CreateJavaVM_inner -> ciReplay::replay -> ciReplay::replay_impl -> process-> process_command -> process_ciMethodData` and that only ever happens single-threaded.

Of course, if we are ever going to implement [JDK-8254110](https://bugs.openjdk.org/browse/JDK-8254110), we need to revisit that code, but in that case the assert that I added will trigger.

What do you think?

> Method::build_method_counters doesn't appear to be lock-free, in the sense there are no atomic operations; rather concurrency just doesn't seem to be a concern with that code. ??

It uses the exact same mechanism that I now added to `Method::build_profiling_method_data`, including atomic operations to initialize `_method_counters`:
https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L651-L654

And I verified that multiple threads attempt to initialize the counters by adding verification code to:
https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646

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

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