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

[dean.long at oracle.com]

Thanks Dan!

dl


On 8/31/16 10:38 AM, Daniel D. Daugherty wrote:
> 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
>>
>>
>