RFR: 8221554: aarch64 cross-modifying code

[Erik Österlund]

On Thu, 1 Oct 2020 08:35:06 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>> I am about to integrate concurrent stack scanning for ZGC. This patch changes things a bit so that disarming of the
>> poll word is always done only by the thread itself. The consequence is that if a thread is in native or blocked, and
>> the safepoint finishes, then the thread will when waking up, still take one slow path to figure out all is done, disarm
>> the poll and run the cross modifying fence. The consequence is that we trivially need the cross modifying fence only in
>> the poll slow path and nowhere else. So maybe if you wait for that one, we can delete a few more ISBs, and IMO also
>> delete the verification code, as you can't really mess it up any more.
>
>> I am about to integrate concurrent stack scanning for ZGC. This patch changes things a bit so that disarming of the
>> poll word is always done only by the thread itself. The consequence is that if a thread is in native or blocked, and
>> the safepoint finishes, then the thread will when waking up, still take one slow path to figure out all is done, disarm
>> the poll and run the cross modifying fence. The consequence is that we trivially need the cross modifying fence only in
>> the poll slow path and nowhere else. So maybe if you wait for that one, we can delete a few more ISBs, and IMO also
>> delete the verification code, as you can't really mess it up any more.
> 
> I'd need to see what the code looks like - but I'm thinking it just reduces the number of cross_modify_fence calls,
> instead of reducing explicit isb calls in the backend (of which only 3 remain with this patch). Either way, it's good
> news. I'm going to try rebasing locally on the top of your patch (I'm assuming it's this one
> https://github.com/openjdk/jdk/pull/296 ) and see where that gets me.  I'd be cautious about removing the verification
> code - it should be useful for helping to catch issues if we do start getting  1 run in a million crash dumps. But
> agreed, doesn't need to be there if the whole isb process has become trivial.

You no longer need any isb when returning from the native wrappers (interpreted or compiled variant) after my patch.
That *should* be 2 if the mentioned 3 hooks (without looking closely at the code). Because that will be done in the
runtime instead when waking up from native. Which hook do we have left?

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

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