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

[Erik Österlund]

Hi Roman,

When ZGC can not satisfy allocations due to relocation in barriers, it 
pins the object to the from-space page,
so that it can not move. It will have to sit tight until the next GC to 
move.

/Erik

On 2020-04-07 15:26, Roman Kennke wrote:
> 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
>>>