RFR: 8221554: aarch64 cross-modifying code

Patricio Chilano Mateo pchilanomate at openjdk.java.net
Tue Oct 13 16:49:11 UTC 2020


On Tue, 13 Oct 2020 09:00:38 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.
>> 
>> 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.

Regarding the use of cross_modify_fence(), I filed a bug last week to remove some uneeded uses of them in common code
(https://bugs.openjdk.java.net/browse/JDK-8254264). Just a heads up before I send the RFR since I see some reference to
them in the added comments.

Thanks,
Patricio

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

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


More information about the hotspot-dev mailing list