8212205 (XS) VM asserts after CDS archive has been unmapped
Ioi Lam
ioi.lam at oracle.com
Thu Oct 25 19:10:57 UTC 2018
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
>> _shared_metaspace_{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 is_shared() const {
>> return (((void*)this) < _shared_metaspace_top && ((void*)this) >=
>> _shared_metaspace_base);
>> }
>> }
>>
>> The fix is to reset those pointers after CDS has been unmapped.
>>
>> Thanks
>> - Ioi
>>
>
More information about the hotspot-runtime-dev
mailing list