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