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