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.
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
More information about the hotspot-dev
mailing list