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

[Zhengyu Gu]

Thanks, Erik.

-Zhengyu

On 4/7/20 10:16 AM, Erik Österlund wrote:
> Hi Zhengyu,
> 
> That sounds good. Ship it.
> 
> Thanks,
> /Erik
> 
> On 2020-04-07 16:07, Zhengyu Gu wrote:
>>
>>
>> On 4/7/20 9:15 AM, Erik Österlund wrote:
>>> NVM, it seems like the closure takes care of that. Have you tried 
>>> with ZGC too, to sanity check that?
>>
>> I ran the same tests that break Shenandoah with ZGC, they seem fine.
>>
>> What else should I try?
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>>
>>> /Erik
>>>
>>> On 2020-04-07 15:09, Erik Österlund wrote:
>>>> 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
>>>>>
>>>>
>>>
>>
>