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

[Daniel D. Daugherty]

On 8/30/16 1:24 PM, dean.long at oracle.com wrote:
> http://cr.openjdk.java.net/~dlong/8156137/webrev/

src/share/vm/oops/klass.cpp
     No comments.

Thumbs up!

Long and probably frustrating hunt for this one.
Good job on catching it!

Dan


>
> 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
>
>