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

Erik Österlund erik.osterlund at oracle.com
Tue Apr 7 14:16:30 UTC 2020


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
>>>>
>>>
>>
>




More information about the hotspot-gc-dev mailing list