RFR: 8221554: aarch64 cross-modifying code [v3]

[Alan Hayward]

On Thu, 12 Nov 2020 15:57:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Alan Hayward has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - AArch64: Add cross modify fence verification
>>  - AArch64: Use cross_modify_fence instead of maybe_isb
>>  - Split cross_modify_fence
>
> Still pending.

> 
> > The problem is it massively slows down a run. A tier1 test run for fastdebug went from 1h 32m 58s to
> > 3h 43m 47s. I didn't think that would be acceptable.
> 
> But why is it so expensive? All it does is mark the threads at a safepoint
> and later check the mark at safepoints. It's not as if it's doing anything
> much, but you're telling me it is more expensive than everything else put
> together.
> 

Ok, please ignore my comment about slowdowns.
Turns out that our testing infrastructure had been scheduling onto different boxes. Once forced onto a single machine, I see no real difference in a complete tier 1 run with and without VerifyCrossModifyFence. (With the slower boxes taking ~4 hours and a quicker one taking ~1 hours)

Patch updated to enable VerifyCrossModifyFence always for aarch64 debug.
 
> > I wanted to avoid mentioning code that no longer exists. (Maybe it's best to just drop the comment?)
> 
> The comment only makes sense in the context of the code that was there
> before.
> 
> > How about:
> > // When we return from the VM, the instruction stream may have
> > // been modified. Therefore needs an isb is required. The VM will
> > // have already done this by calling cross_modify_fence().
> 
> This is self contradicting: firstly you say and ISB is required, then
> you say why it isn't.

Agreed. The comment only makes sense when it refers to code that used to exist. And I really dislike comments that do that. So, I've dropped them completely.

> // Finally, we define an "instruction_fence" operation, which ensures that all
> // instructions that come after the fence in program order are fetched
> // from the cache or memory after the fence has completed

Done.

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

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