RFR (S) JDK-8162553: Crash in class unloading due to null CLD having a zero _keep_alive value

Lois Foltan lois.foltan at oracle.com
Tue Aug 9 21:03:56 UTC 2016


On 8/8/2016 8:48 PM, David Holmes wrote:
> Hi Lois,
>
> On 9/08/2016 5:41 AM, Lois Foltan wrote:
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8162553/webrev/
>>
>> Bug: Crash in class unloading due to null CLD having a zero _keep_alive
>> value
>> https://bugs.openjdk.java.net/browse/JDK-8162553
>>
>> Summary:
>> Limit the increment/decrement of the ClassLoaderData _keep_alive field
>> to just ClassLoaderData(s) created specifically for an anonymous class.
>
> That sounds reasonable but I wonder whether this should be checked in 
> the calling code rather than inside those methods? Otherwise in the 
> calling code there is an appearance that all CLDs need a keep-alive 
> count, when they don't. A comment in classLoaderData.hpp that those 
> methods only apply to anonymous classes would also add some clarity to 
> the API.

Thank you David for the review.  I would prefer keeping the check for an 
anonymous ClassLoaderData within the increment/decrement methods.  The 
comments in classLoaderData.hpp at ClassLoaderData's _keep_alive field 
declaration are clear that this is used for an anonymous class's 
ClassLoaderData.  I have added additional comments ahead of the 
increment/decremement declarations in classLoaderData.hpp as well to 
ensure that this is well documented.

Thanks,
Lois

>
> Thanks,
> David
>
>> Due to the uniqueness that no other class shares an anonymous class'
>> ClassLoaderData, no other non-GC thread has knowledge of the anonymous
>> class while it is being defined.  By limiting the increment/decrement to
>> just ClassLoaderData(s) dedicated to anonymous classes, the need to make
>> this an atomic operation is avoided.  This bug was exposed since
>> java_lang_Class::create_mirror() is multi-threaded once java.lang.Class
>> is loaded during JVM start up.
>>
>> Testing:
>> Several runs of hotspot nightly testing and several iterations of
>> various tests that have exposed this issue.
>>
>> Thanks,
>> Lois



More information about the hotspot-dev mailing list