RFR(S) 8156137: SIGSEGV in ReceiverTypeData::clean_weak_klass_links

dean.long at oracle.com dean.long at oracle.com
Tue Aug 30 19:24:59 UTC 2016



The problem: JVMTI RedefineClasses creates scratch classes to hold the 
old methods until they can be freed (they are no longer active in a 
thread stack).  G1ConcurrentMark sees these scratch classes, but 
G1MarkSweep does not.

The details:

G1ConcurrentMark uses ClassLoaderDataGraphKlassIteratorAtomic to iterate 
over *all* classes and calls clean_weak_instanceklass_links to clean.

G1MarkSweep (and other GCs) use Klass::clean_weak_klass_links() to 
iterate over *live, non-scratch* classes, and calls 
clean_weak_instanceklass_links to clean.

Now the problem scenario is:

0: scratch class S has MethodData that references a class U that is 
going to be unloaded.

1: G1MarkSweep skips class S in Klass::clean_weak_klass_links, because 
scratch classes are not added to the class hierarchy tree. The full GC 
then frees the metadata for class U. Now the MethodData for S contains 
stale metadata.

2. When a later G1ConcurrentMark calls clean_weak_instanceklass_links on 
S, it will crash on the stale metadata.

Solution: have Klass::clean_weak_klass_links() process these scratch 
classes that can be found on the "previous versions" list.

Tested with bigapps/Kitchensink.


More information about the hotspot-runtime-dev mailing list