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