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

[Coleen Phillimore]

This looks good.  Could you make _keep_alive a short so there isn't such 
a big alignment gap in CLD?
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
>>>
>