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

David Holmes david.holmes at oracle.com
Fri Oct 26 04:27:04 UTC 2018


+1

Thanks for jumping on this one Ioi!

David

On 26/10/2018 1:58 PM, Jiangli Zhou wrote:
> 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