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

[Ioi Lam]

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
>