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
http://cr.openjdk.java.net/~dlong/8156137/webrev/
https://bugs.openjdk.java.net/browse/JDK-8156137
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.
dl
More information about the hotspot-compiler-dev
mailing list