RFR: 8065634: Crash in InstanceKlass::clean_method_data when _method is NULL

[Coleen Phillimore]

Good.
Coleen

On 12/11/14, 5:20 AM, Stefan Karlsson wrote:
> Hi all,
>
> FYI, this patch is being backported to 8u40. The JDK 9 Nighly testing 
> looks good and the patch applies cleanly to 8u40.
>
> StefanK
>
> On 2014-12-03 15:21, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to fix an issue where the GC encounters an 
>> InstanceKlass before it has come far enough in the class loading 
>> process.
>>
>> Some background to the fix:
>>
>> When the JVM loads classes it has to keep track of the allocated 
>> Metadata, and in the event of an exception deallocate the Metadata. 
>> The ClassFileParser saves the Metadata pointers so that it knows what 
>> needs to be deallocated. When the class loading has come far enough 
>> there's a point were the GC can take over the ownership of the 
>> Metadata and do deallocation of the both the InstanceKlass and the 
>> Metadata, if needed. At that point the Metadata pointers in the 
>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>
>> Most Metadata allocations happen before the InstanceKlass is 
>> allocated, but the Annotations are allocated after the InstanceKlass 
>> but before the transferal and clearing of the Metadata pointers in 
>> the ClassFileParser. If the GC stops when allocating the Annotations, 
>> it will likely find this InstanceKlass and assume that the Metadata 
>> are correctly setup. This is exactly what's happening in the bug 
>> report. The GC finds that the _methods array, unexpectedly, points to 
>> NULL.
>>
>> The proposed solution to this problem is to allocate the Annotations 
>> before the InstanceKlass is allocated.
>>
>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>
>> Testing:
>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>
>> Thanks,
>> StefanK
>