8212205 (XS) VM asserts after CDS archive has been unmapped
Ioi Lam
ioi.lam at oracle.com
Fri Oct 26 03:53:35 UTC 2018
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