RFR: 8268364: jmethod clearing should be done during unloading

[Daniel D.Daugherty]

On Thu, 1 Jul 2021 00:06:45 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 2261:
> 
>> 2259:   }
>> 2260:   // Method should otherwise be valid. Assert for testing.
>> 2261:   assert(is_valid_method(o), "should be valid jmethodid");
> 
> nit typo: s/jmethodid/jmethodID/

I think you need a comment for L2262 to explain why you return NULL
when the class loader is no longer alive. I think it's because it's racy
if the class loader is no longer alive to return the jmethodID.

However, if that is racy, then does that mean that the above new assert()
is also racy?

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

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