RFR 8225483: Shenandoah: Enhance native access barrier
Roman Kennke
rkennke at redhat.com
Tue Jun 11 15:51:06 UTC 2019
OK by me.
Thanks!
Roman
Am 11. Juni 2019 16:25:21 MESZ schrieb Zhengyu Gu <zgu at redhat.com>:
>Updated: http://cr.openjdk.java.net/~zgu/JDK-8225483/webrev.02/
>
>Okay now?
>
>Thanks,
>
>-Zhengyu
>
>On 6/11/19 6:43 AM, Roman Kennke wrote:
>> I think it returns either NULL or passes through LRB, I think this is
>
>> fine and does not leak from-space-refs.
>>
>> Roman
>>
>>
>> Am 11. Juni 2019 11:23:12 MESZ schrieb Aleksey Shipilev
><shade at redhat.com>:
>>
>> On 6/11/19 1:14 AM, Zhengyu Gu wrote:
>>
>> 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/
>>
>>
>> This patch cannot go to jdk/jdk. It can only go to sh/jdk.
>>
>> *) This block:
>>
>> 99 ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> 100 shenandoah_assert_marked_if(NULL, value,
>!CompressedOops::is_null(value) &&
>> heap->is_evacuation_in_progress());
>>
>> Can be just:
>>
>> shenandoah_assert_marked_if(NULL, value,
>!CompressedOops::is_null(value) &&
>> ShenandoahHeap::heap()->is_evacuation_in_progress());
>>
>> *) After the change above is done, you can make
>SBS::oop_store_not_in_heap available always: e.g.
>> drop the ASSERT around it.
>>
>> *) I think the block in oop_load_not_in_heap needs the comment
>why this is done. This is a weird
>> exception anyway: it leaks the from-space pointers from the weak
>roots, no? What actually guarantees
>> we would not store that from-space pointer somewhere *on heap*?
>>
>> *) This block can be simplified:
>>
>> ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> if (heap->is_evacuation_in_progress()) {
>> ShenandoahMarkingContext* const marking_context =
>heap->complete_marking_context();
>> if (!marking_context->is_marked(value)) {
>> return NULL;
>> }
>> }
>>
>> to:
>>
>> ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> if (heap->is_evacuation_in_progress() &&
>!heap->complete_marking_context()->is_marked(value)) {
>> return NULL;
>> }
>>
>> -Aleksey
>>
>>
>> --
>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
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/98e1261a/attachment.htm>
More information about the hotspot-gc-dev
mailing list