RFR (xs): 8170959 unloading archived shared class caused crash

[Coleen Phillimore]

Yes, I think this looks a lot better.
Thanks!
Coleen

On 1/4/17 8:09 PM, Ioi Lam wrote:
> Hi Coleen,
>
> Thanks for the suggestion. I've removed the assert. I needed to add a 
> check for the _cached_class_file because for shared classes this field 
> is not allocated from the C heap, but rather points into the shared 
> archive.
>
> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v02/ 
>
>
> Thanks
> - Ioi
>
> On 1/4/17 3:54 PM, Coleen Phillimore wrote:
>>
>> Hi Ioi,
>>
>> It seems like there would be leaks if you don't release some of these 
>> C_heap structures.  Should the assert just be removed?
>> Except the constant pool release_C_heap_structures unreferences 
>> symbols, and that shouldn't be done if the constant pool is shared.
>> thanks,
>> Coleen
>>
>> On 1/4/17 6:33 PM, Ioi Lam wrote:
>>> Hi,
>>>
>>> Please review this small fix:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8170959
>>> http://cr.openjdk.java.net/~iklam/jdk9/8170959-archived-shared-class-unloading.v01/ 
>>>
>>>
>>> Please note that this is a closed bug and it's related to unloading
>>> shared classes loaded by custom class loaders. The test case is
>>> in the closed repo.
>>>
>>> The bug happened with the following call stack
>>>
>>>         "assert(!this->is_shared()) failed"
>>>     in InstanceKlass::release_C_heap_structures ()
>>>     in InstanceKlass::release_C_heap_structures ()
>>>     in ClassLoaderData::classes_do 
>>> (f=<InstanceKlass::release_C_heap_structures(InstanceKlass*)>)
>>>     in ClassLoaderData::~ClassLoaderData ()
>>>     in ClassLoaderDataGraph::purge ()
>>>     in G1CollectedHeap::do_full_collection ()
>>>
>>> The fix is to avoid doing the clean up if the unloaded class is shared.
>>> Proper clean up is deferred to JDK 10 (bug JDK-8140287).
>>>
>>> Thanks
>>> - Ioi
>>
>