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