When testing JDK-8341913, I have seen crashes that look like java.lang.Class mirror (CM) pointing to a dead InstanceKlass (IK). That CM is still alive from GC perspective. There is a 1:1 link IK->CM and CM->IK. Normal IK deallocation code nullptr-s the link between CM and IK when deallocating, and the rest of the code checks if CM's link to IK is nullptr. So when IK is deallocated, its relevant CM does not point to any garbage IK anymore.
However, CDS dumping code produces another "scratch" CM* -> IK. IK knows only about original CM, and not about the additional CM*. CDS code tries to clean it up when IK is deallocating, but it does so incompletely: it does not break the link between scratch CM* and IK, like the normal path does. So after class unloading, we have a "live" scratch CM* mirror that points to dead IK, and GC crashes.
We should break the link between scratch CM* and their IK in CDS dumping code as well.
However, CDS dumping code produces another "scratch" CM* -> IK. IK knows only about original CM, and not about the additional CM*. CDS code tries to clean it up when IK is deallocating, but it does so incompletely: it does not break the link between scratch CM* and IK, like the normal path does. So after class unloading, we have a "live" scratch CM* mirror that points to dead IK, and GC crashes.
We should break the link between scratch CM* and their IK in CDS dumping code as well.
- blocks
-
JDK-8341913 Support CDS heap dumping for Shenandoah and Epsilon
- Resolved
- links to
-
Commit(master) openjdk/jdk/aa060f22
-
Review(master) openjdk/jdk/21531