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

Harold David Seigel harold.seigel at oracle.com
Thu Oct 25 19:22:41 UTC 2018

Hi Ioi,

That sounds good.

Thanks, Harold

On 10/25/2018 3:10 PM, Ioi Lam wrote:

Hi Harold,

On 10/25/18 11:34 AM, Harold David Seigel wrote: HI Ioi,

This looks good. What regression tests were run? I did manual testing to trigger the condition, and could reproduce it 100% before, and could not reproduce after the fix. This is an intermittent failure but has happened a lot in tier 1, I'll do a round of tier1/2 testing before pushing. But I guess we needs a few weeks of runs to confirm that the intermittent failures don't happen anymore. Thanks - Ioi Thanks, Harold On 10/25/2018 2:22 PM, 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