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

Stefan Karlsson stefan.karlsson at oracle.com
Thu Dec 11 10:20:11 UTC 2014

Hi all,

FYI, this patch is being backported to 8u40. The JDK 9 Nighly testing 
looks good and the patch applies cleanly to 8u40.


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

More information about the hotspot-dev mailing list