RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v6]

[Jaroslav Bachorik]

On Thu, 23 Nov 2023 15:19:43 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 541:
>> 
>>> 539:       assert (!method->on_stack(), "shouldn't be called with methods on stack");
>>> 540:       // Do the pointer maintenance before releasing the metadata
>>> 541:       method->clear_jmethod_id();
>> 
>> IIUC this is O(n^2) over number of methods. Seeing that this is a workaround for a special case (an app that does a lot of retransforms *and* uses async profiler), I'd opt for making it conditional.
>
> Sadly, this is not async-profiler specific. The same issue can be observed by JVMTI only code grabbing a stacktrace.
> What do you mean exactly by 'conditional'? Introducing a new JVM flag or something else?

Ok, I see now - I could do the jmethodID maintenance only from `purge_previous_version_list()` call, leaving the proper metaspace deallocation untouched, therefore not adding unnecessary overhead there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16662#discussion_r1403544462