RFR: 8313816: Accessing jmethodID might lead to spurious crashes

[Coleen Phillimore]

On Sat, 18 Nov 2023 00:23:44 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 541:
>> 
>>> 539:       // The previous version will point to them so they're not totally dangling
>>> 540:       assert (!method->on_stack(), "shouldn't be called with methods on stack");
>>> 541:       // Do the pointer maintenance before releasing the metadata, but not for incomplete methods
>> 
>> I'm confused by what you mean by method holder, which I think of as methodHandle.  Or InstanceKlass is the holder of the methods.  Maybe this should be more explicit that it's talking about clearing any associated jmethodIDs.
>
> The method holder is an `InstanceKlass` object which can be retrieved as `method->method_holder()` (I apologize if I am using not completely correct terms - this is what I grokked from the sources). And incomplete methods created by the `ClassParser` from the class data stream will not have the link to that `InstanceKlass` set up if the `ClassParser` is already having its `_klass` field set to a non-null value.
> 
> If we are talking about clearing any jmetbodIDs associated with an `InstanceKlass` instance it is not really possible for old method versions because only the current `InstanceKlass` version has the jmethodID cache associated with it and it contains jmethodIDs pointing to bot the old and current methods.

I see, holder is the right word and concept.  So the parameter means has_method_holder, in that the InstanceKlass has been fully parsed at the point of clearing the jmethodIDs.

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

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