RFR: 8221554: aarch64 cross-modifying code

[Alan Hayward]

On Mon, 12 Oct 2020 13:50:51 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> @a74nh Please do not force-push commits on an open PR as it breaks the commit history and prevents reviewers from
>> seeing what has changed since they last reviewed things. If you need to "rebase" you can just merge your branch with an
>> updated master branch and push the merge commit to your personal fork. The skara tooling will flatten the commits into
>> a single clean commit when integration happens. Thanks.
>
>> @a74nh Please do not force-push commits on an open PR as it breaks the commit history and prevents reviewers from
>> seeing what has changed since they last reviewed things. If you need to "rebase" you can just merge your branch with an
>> updated master branch and push the merge commit to your personal fork. The skara tooling will flatten the commits into
>> a single clean commit when integration happens. Thanks.
> 
> Not a fan of working with merge commits and I feel it gets muddled when you have history on top of a patch series (as
> opposed to a single patch). However, understood - I'll make sure to merge instead of force pushing next time.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_
> 
> So, the good news and the bad news:
> 
> Moving to cross_modify_fence reduces the number of ISBs from
> 3,840,210 maybe_isb()s to 74,538 cross_modify_fence()s on my
> poster child application, which is recompiling all of java.base.
> 
> However, this is a program that runs for 187,501,798,979 insns,
> so we've reduced the proportion of ISBs from 0.002% to 0.00004%.
> I guess that's worth having, but I doubt that the improvement
> would ever have been above the noise level.

Thanks for testing this out.
"Kills 98% of ISBs" is the marketing headline then.
Sadly less effective than I was hoping - which explains my testing results.

> 
> 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)

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/428