RFR: C1 stores constants without read barriers
Aleksey Shipilev
shade at redhat.com
Thu Jun 29 12:04:12 UTC 2017
Well, the symmetry argument still stands: x86 and aarch64 versions should be
consistent. aarch64 makes unconditional RB for store values. I think it makes no
harm to emit RB there for extra safety.
-Aleksey
On 06/29/2017 01:59 PM, Roman Kennke wrote:
> I thought that too. But then realized we don't need barriers on constants for
> store values. Will explain on IRC as soon as my internet conn is back alive...
>
> Am 29. Juni 2017 13:55:31 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>
> I think this part of C1 is incorrect when barriers are required for constants:
> http://cr.openjdk.java.net/~shade/shenandoah/c1-store-const-rb/webrev.01
> <http://cr.openjdk.java.net/%7Eshade/shenandoah/c1-store-const-rb/webrev.01>/
>
> This might explain a few test failures we have: the from-space constant is read
> before concurrent evacuation has the chance to update it. Then it gets stored to
> another heap location, and everything blows up.
>
> While we could conditionalize this on ShBarriersForConst, this is C1 code, which
> does not have to be super-optimal. Surprisingly, the new code is what
> c1_LIRGenerator_aarch64 is already doing, so this patch seems good from the
> symmetry standpoint too.
>
> Testing: hotspot_gc_shenandoah
>
> Thanks,
> -Aleksey
>
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
More information about the shenandoah-dev
mailing list