RFR: 8339725: Concurrent GC crashed due to GetMethodDeclaringClass [v2]

[Erik Österlund]

On Tue, 10 Sep 2024 09:02:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Maybe I'm misunderstanding the test case but isn't it using a jMethodID for a class that may have been unloaded?
>> 
>> Yes.
>
>> > Maybe I'm misunderstanding the test case but isn't it using a jMethodID for a class that may have been unloaded?
>> 
>> Yes.
> 
> Okay then that is a programming error not a VM error. It is up to the application to ensure that classes are kept alive if you have jMethodID's for them:
> 
> https://docs.oracle.com/en/java/javase/22/docs/specs/jni/design.html#accessing-fields-and-methods
> 
> any validation the VM attempts with jMethodId's (and field id's) is best-effort and not required.

Yeah. On an API level @dholmes-ora  is 100% right, and @xmas92 me and @stefank came to the same conclusion. The API implementation absolutely does not have to deal with these errors if we don't want to. We could just ignore it. But similar to @apangin I think that even though we don't have to deal with the error, we probably should do it in practice as some APIs expose jmethodID without the class. You can ask for the class so you know what to keep alive, but that is done literally with this very API, making it a bit more important that it does in fact report the errors correctly. So I think we should be nice here and make it work more robustly. My 50c!

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

PR Comment: https://git.openjdk.org/jdk/pull/20907#issuecomment-2342062140