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

Jiangli Zhou jiangli.zhou at oracle.com
Fri Oct 26 03:58:14 UTC 2018


Looks good!

Thanks,

Jiangli


On 10/25/18 8:53 PM, Ioi Lam wrote:
> Hi Jiangli,
>
> Thanks for your comments. How about this:
>
> http://cr.openjdk.java.net/~iklam/jdk12/8212205-crash-after-cds-unmap.v02/ 
>
>
> - Ioi
>
> On 10/25/18 3:11 PM, Jiangli Zhou wrote:
>> On 10/25/18 1:49 PM, Ioi Lam wrote:
>>
>>> 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.
>> How about adding something like 
>> MetaspaceShared::clear_shared_metaspace (or 
>> MetaspaceShared::reset_shared_metaspace)? It could be called from 
>> MetaspaceShared::stop_sharing_and_unmap (or from metaspace.cpp 
>> directly). The reason I bring it up is because having two public 
>> stop_sharing_and_unmap() APIs is a bit confusing and 
>> FileMapInfo::stop_sharing_and_unmap() is no longer intended to be 
>> used by others for general cases. Or how about making 
>> FileMapInfo::stop_sharing_and_unmap() private (add MetaspaceShared as 
>> a friend to FileMapInfo)?
>>
>> If you want to keep both public APIs, probably consider at least 
>> adding a comment warning about the use of 
>> FileMapInfo::stop_sharing_and_unmap()?
>>
>> Thanks,
>> Jiangli
>>>
>>> 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
>>>>>
>>>>
>>>
>>
>



More information about the hotspot-runtime-dev mailing list