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

[Tobias Hartmann]

On Wed, 30 Nov 2022 06:28:08 GMT, David Holmes <dholmes 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
>
>> It uses the exact same mechanism that I now added to Method::build_profiling_method_data, including atomic operations to initialize _method_counters
> 
> Sorry I somehow missed the `init_method_counters` logic. :(

@dholmes-ora, @dean-long are you okay with the latest version?

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

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