RFR: 8221554: aarch64 cross-modifying code

Andrew Haley aph at redhat.com
Tue Oct 13 14:16:52 UTC 2020


On 13/10/2020 10:03, Alan Hayward wrote:
>> On the good side, this at least makes AArch64 more like other
>> targets.
>>
> Yes. This should give all the goodness from using common code
> (simpler, stronger code, etc etc)

Well, maybe.

My thinking was that the common cross_modify_fence() code was untested
and possibly incorrect, whereas I was pretty sure maybe_isb() was used
wherever necessary and in fact conservatively even where it wasn't
actually necessary. So I didn't really want AArch64 to be the victim.
:-)

> To be clear, the four original reasons for the patch were:
> *Use common code/interfaces where possible
> *Reduce ISBs where AArch64 was being too cautious
> *Add ISBs if theres any paths without them   (there weren't)
> *Confirm the above changes are safe.

Yep.

One interesting thing is that while the AArch64 non-coherent Icache
and the rules for "Concurrent modification and execution of
instructions" are annoying, they don't make a practical difference to
the execution time of Java programs. It's a pain to have to program
all of this stuff, but in performance terms the decision of the Arm
architects has been vindicated.

-- 
Andrew Haley  (he/him)
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



More information about the hotspot-dev mailing list