RFR: C1 stores constants without read barriers

Roman Kennke rkennke at redhat.com
Thu Jun 29 12:13:22 UTC 2017


IIRC, it doesn't compile like this. If it's not a reg, it needs to emit a mov from const to reg.

Roman

Am 29. Juni 2017 14:04:12 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>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.

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


More information about the shenandoah-dev mailing list