RFR: 8268364: jmethod clearing should be done during unloading

[Coleen Phillimore]

On Thu, 1 Jul 2021 00:12:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This patch moves the jmethod clearing to ClassLoaderData::unload() but also adds a check to Method::checked_resolved_jmethod_id() to handle the case where ZGC may be unloading a class but not have gotten to ClassLoaderData::unload() yet.  JVMTI will read a NULL method for checked_resolved_jmethod_id() in this case, and not get a Method that will shortly, or has already been reclaimed in the Metaspace destructor.
>> Since I was there, I also added Method::is_valid_method() check to checked_resolve_jmethod_id. I don't think it's expensive anymore but it could be added under DEBUG.  Either way method->method_holder()->is_loader_alive() will crash if !is_valid_method so we should leave it.   As I wrote in the related issues, the bogus Method may have been because of a previous set of bugs with post_compiled_method_load events.
>> 
>> Tested with tiers 1-6 on linux-x64-debug and 1-3 on windows-x64-debug.
>> 
>> Also ran vmTestbase/nsk/{jdi,jvmti} tests with VM_OPTIONS=-XX:+UseZGC  -XX:ZCollectionInterval=0.01 -XX:ZFragmen
>> tationLimit=0
>
> src/hotspot/share/oops/method.cpp line 2257:
> 
>> 2255:   if (mid == NULL) return NULL;
>> 2256:   Method* o = resolve_jmethod_id(mid);
>> 2257:   if (o == NULL || o == JNIMethodBlock::_free_method) {
> 
> I need to think more about deleting the is_method() check.

The is_method() check was from when JNIHandleBlocks contained both jmethodID's and jobjects.  It's a leftover from permgen elimination. I should have mentioned that in the PR comments.  Now the only things that can be put in the JNIMethodBlocks are Methods, which the compiler type-checks, so that's the only thing that can come out (unless corrupted).

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

PR: https://git.openjdk.java.net/jdk/pull/4643