ShenandoahBarrierSetC2::escape_is_barrier_node

Roman Kennke rkennke at redhat.com
Thu Jun 13 15:44:39 UTC 2019


So removing it altogether would be fine and harmless?

Roman


Am 13. Juni 2019 17:43:09 MESZ schrieb Roland Westrelin <rwestrel at redhat.com>:
>
>Hi Aleksey,
>
>> A question for you. We have a staged code in sh/jdk, which has this
>change in
>> ShenandoahBarrierSetC2::escape_is_barrier_node:
>>   http://hg.openjdk.java.net/shenandoah/jdk/rev/3f2b4cc07dbd#l1.47
>
>I think it's fine to keep that change because we remove barriers on
>newly allocated objects and that code is for barriers on newly
>allocated
>non escaping objects. The reason we hit AFAICT is:
>
>changeset:   56234:3f2b4cc07dbd
>tag:         tip
>user:        shade
>date:        Thu Jun 06 22:24:23 2019 +0200
>summary:     C2 LRB self-fixup
>
>because it adds a new edge to the load barrier and so a path to the
>barrier from a newly allocated object even when we don't apply the
>barrier to the object itself but to a field loaded from that object.
>
>Actually, I would say it's a left over from when we had an option to
>not
>optimize out barriers on newly allocated objects and has not been
>needed
>for a while.
>
>Roland.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


More information about the shenandoah-dev mailing list