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

[Lois Foltan]

On 8/10/2016 9:24 AM, Coleen Phillimore wrote:
>
> This looks good.  Could you make _keep_alive a short so there isn't 
> such a big alignment gap in CLD?

Thanks Coleen for the review!  Done, changed to a type of "s2".
Lois

> thanks,
> Coleen
>
> On 8/10/16 8:31 AM, Lois Foltan wrote:
>> Thanks David!
>> Lois
>>
>> On 8/9/2016 7:34 PM, David Holmes wrote:
>>> On 10/08/2016 8:09 AM, Lois Foltan wrote:
>>>>
>>>> On 8/9/2016 5:57 PM, Karen Kinnear wrote:
>>>>> Code looks good. Agree with David about comment about use - for the
>>>>> _keep_alive field: for
>>>>> loaders never unloaded (boot now, platform and application I would
>>>>> expect us to add), and for
>>>>> anonymous classes via reference count methods.
>>>>
>>>> Thank you Karen for the review.  I have improved upon the comments as
>>>> requested.
>>>>
>>>> Updated webrev at:
>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8162553.1/webrev/
>>>
>>> Looks ok.
>>>
>>> Thanks,
>>> David
>>>
>>>> Lois
>>>>
>>>>>
>>>>> thanks,
>>>>> Karen
>>>>>
>>>>>> On Aug 8, 2016, at 3:41 PM, Lois Foltan <lois.foltan at oracle.com> 
>>>>>> 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.  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
>>>>
>>
>