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

Coleen Phillimore coleen.phillimore at oracle.com
Wed Jan 4 23:54:23 UTC 2017


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



More information about the hotspot-runtime-dev mailing list