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

[Ioi Lam]

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

- Ioi

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::stop_sharing_and_unmap() 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
>> _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
>>
>