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

[Erik Österlund]

On Wed, 11 Sep 2024 07:29:12 GMT, Liang Mao <lmao at openjdk.org> wrote:

> > // Why can't k already be not-alive here?
> 
> No. `k` can't be already dead here. is_loader_alive already returned true. `k` could be dead later so we need to make sure the resurrection if it needs access.

Right. An oop dies after marking has terminated and it was not reachable other than potentially from phantom references. In this case, the oop isn't dead *yet*, but it is also only reachable through a phantom reference from the metadata, in the object graph. The oop will die unless something is done about it. If you pick out an oop that is not strongly reachable in the object graph, you could think of it as a sort of "zombie oop". You usually get to them through AS_NO_KEEPALIVE loads and people know to be careful then, but since CLD oops are a bit weird, this is another vector to zombie oops, because the model is not obvious that CLD oops (such as java_mirror) should only be usable after loading the holder (in a vm weak resolving way that keeps it alive). When acquiring such zombie oops that are "dying", you are not allowed to expose them to the object graph (such as putting them into a handle). Because while it isn't dead yet, it will be soon unless kept alive (until the next safepo
 int).

I realize it's problematic that very few people know how these obscure metadata interactions work, and it would probably be a good idea to try to improve our internal APIs to make it harder to mess up. But the current design that we have, is that if you grab metadata from out of nowhere, you have to load its holder to keep it alive (at least until the next safepoint), before you expose any of its CLD oops (such as java_mirror) in the object graph. We rarely get random metadata from out of nowhere, because you typically get to a klass from a strongly reachable object, which keeps its metadata alive. But every now and then this pops up and it's rather obscure.

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

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