[aarch64-port-dev ] JDK 13 AArch64 issues to backport

[Andrew Haley]

On 6/19/19 5:50 PM, Aleksey Shipilev wrote:
> On 6/19/19 6:37 PM, Andrew Dinn wrote:
>> Ok, to get this ball rolling, here is my list of what really ought to be
>> backported (to both or either of 8u) and then at the end what can
>> probably be ignored.
>>
>> Note I have not (yet) checked all the patches to be sure they are
>> actually applicable for 11 or 8. This is just a first cut to say they
>> are worth checking.
>>
>> Am I supposed to backport them now or is anyone else going to step in?
> 
> Yes, I think we can start with 11u, which is open for pushes (for 11.0.5). 8u is more complicated,
> because we would probably like to wait for the aarch64-port/jdk8u-shenandoah tree to finish current
> CPU cycle.
> 
>> No, don't bother to backport
>>
>>>   8221995: AARCH64: problems with CAS instructions encoding
> 
> This looks like a hard to diagnose bug that might only manifest in complicated compilations. Do we
> really not care about this?

That one only affects something that is never used. We don't use SP, ZR,or CAS pair.

>>>   8218185: aarch64: missing LoadStore barrier in TemplateTable::putfield_or_static
>>>   8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield
>>>   8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable
> 
> It is a bit awkward that they are backported to 8u, but not to 11u, so maybe just the consistency
> reasons make them good candidates for 11u backports? Do we think these three are not affecting
> correctness at all? They don't seem to be harmful for performance, as they affect the interpreter only.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671