[15] RFR 8242216: ObjectSampler::weak_oops_do() should not trigger barrier

Roman Kennke rkennke at redhat.com
Tue Apr 7 13:26:55 UTC 2020


Hi Erik,

I am wondering, how does ZGC deal with the situation when GC runs out of
memory and cannot fulfil the relocation? How does it coordinate Java
threads and GC threads (and possibly other threads) to get out of this
without possibly causing heap corruption?

Roman


> Hi Zhengyu,
> 
> This change breaks ZGC. The raw oop may not have been relocated. It was
> not by accident that I used an access load instead of a raw load,
> when I built the leak profiler support.
> Since this kind of issue keeps on popping up, where you can't deal with
> access barriers because of some Shenandoah OOM handler,
> perhaps your barriers need to be fixed instead to deal with these issues
> instead. I predict it is not the last time we have
> to restructure the shared code because of Shenandoah's OOM handler.
> 
> Thanks,
> /Erik
> 
> On 2020-04-06 20:22, Zhengyu Gu wrote:
>> Hi,
>>
>> This is a similar problem as JDK-8237396.
>>
>> Shenandoah does not expect barriers on it GC paths. Otherwise, it
>> causes Shenandoah's OOM handler to fail.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242216
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242216/webrev.00/index.html
>>
>> Test:
>>   tier1 (fastdebug and release) on Linux x86_64
>>   Submit tests.
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
> 




More information about the hotspot-gc-dev mailing list