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

[Harold David Seigel]

Hi Ioi,

That sounds good.

Thanks, Harold

On 10/25/2018 3:10 PM, Ioi Lam wrote:
> 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
>>>
>>
>