RFR 8225483: Shenandoah: Enhance native access barrier
Roman Kennke
rkennke at redhat.com
Tue Jun 11 10:39:58 UTC 2019
It looks to me like it adds more work, while not reaping the benefit of it, specifically the ability to clean some roots concurrently. I assume this would come in follow-up?
Roman
Am 11. Juni 2019 01:14:48 MESZ schrieb Zhengyu Gu <zgu at redhat.com>:
>
>
>On 6/10/19 4:32 AM, Aleksey Shipilev wrote:
>> On 6/10/19 2:06 AM, Zhengyu Gu wrote:
>>> Please review this enhancement of native access barrier, in
>preparation for concurrent root processing.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225483
>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225483/webrev.00/
>>
>> *) It looks to me the webrev itself and the patch in it disagree. For
>example, webrev says the
>> entire oop_store_not_in_heap is #ifdef ASSERT-ed, but the patch has
>the ASSERT block internally. The
>> patch also has the unrelated change in shenandoahForwarding.hpp.
>
>Sorry, it is a broken webrev.
>
>Updated: http://cr.openjdk.java.net/~zgu/JDK-8225483/webrev.01/
>
>Reran hotspot_gc_shenandoah (fastdebug and release)
>
>Thanks,
>
>-Zhengyu
>
>>
>> *) Why change Raw::oop_store_in_heap to Raw::oop_store in
>ShenandoahBarrierSet::oop_store_in_heap?
>>
>> *) You can write this block:
>>
>> #ifdef ASSERT
>> ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> shenandoah_assert_marked_if(value,
>heap->is_gc_in_progress_mask(ShenandoahHeap::EVACUATION));
>> #endif
>>
>> as:
>>
>> shenandoah_assert_marked_if(value,
>ShenandoahHeap::heap()->is_evacuation_in_progress());
>>
>>
>> *) Also, this block:
>>
>> ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> if (!CompressedOops::is_null(value) &&
>> heap->is_gc_in_progress_mask(ShenandoahHeap::EVACUATION)) {
>>
>> as:
>>
>> if (!CompressedOops::is_null(value) &&
>ShenandoahHeap::heap()->is_evacuation_in_progress()) {
>>
>>
>>
>> -Aleksey
>>
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190611/04edc9f7/attachment.htm>
More information about the hotspot-gc-dev
mailing list