8212205 (XS) VM asserts after CDS archive has been unmapped (original) (raw)

Ioi Lam ioi.lam at oracle.com
Thu Oct 25 20:49:26 UTC 2018

MetaspaceObj::_shared_metaspace_top is a private field. MetaspaceShared can modify the field because it's a friend class of MetaspaceObj. I don't want to add more friend classes. Also, I think FileMapInfo class is more like an internal class for MetaspaceShared and other classes should avoid using it.

Thanks

On 10/25/18 12:20 PM, Jiangli Zhou wrote:

Hi Ioi,

The fix looks good, but it's probably better to fix it in FileMapInfo::stopsharingandunmap() directly? Thanks, Jiangli

On 10/25/18 11:22 AM, Ioi Lam wrote: https://bugs.openjdk.java.net/browse/JDK-8212205 http://cr.openjdk.java.net/~iklam/jdk12/8212205-crash-after-cds-unmap.v01/

This is a silly bug but it happens only rarely, when address space randomization causes insufficient memory to be reservable at addresses required by CDS. In this case, the CDS archive is unmapped, but we forget to clean up sharedmetaspace{base,top}. As a result, the JVM will misidentify metaspace objects allocated in certain address ranges to be "shared", in the following function: class MetaspaceObj { bool isshared() const { return (((void*)this) < sharedmetaspacetop && ((void*)this) >= sharedmetaspacebase); } } The fix is to reset those pointers after CDS has been unmapped. Thanks - Ioi

More information about the hotspot-runtime-dev mailing list