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