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

[David Holmes]

On Mon, 28 Nov 2022 14:33:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> `Method::build_profiling_method_data` acquires the `MethodData_lock` when initializing `Method::_method_data` to prevent multiple allocations by different threads. The problem is that when metaspace allocation fails and `JvmtiExport::should_post_resource_exhausted()` is set, we assert during the `ThreadToNativeFromVM` transition in JVMTI code.
>> 
>> Since concurrent initialization is a rare event, I suggest to get rid of the lock and perform the initialization with a `cmpxchg`, similar to how method counters are initialized:
>> https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646
>> 
>> Since [current code](https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.inline.hpp#L41-L46) in `Method::set_method_data` uses a `Atomic::release_store`, I added a `OrderAccess::release()`.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely removed MethodData_lock

> I therefore think it's fine to avoid a lock in this case. Also, we already use a lock-free mechanism for `Method::build_method_counters`.

`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. ??

But as long as the overhead is low and interference unlikely, then we can see how this works out in practice. Thanks.

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

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