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

[Alan Hayward]

On Fri, 23 Oct 2020 10:15:38 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 six commits:
>> 
>>  - Merge master
>>    
>>    Change-Id: I97df4e7686699478f0f89451ec0a3537d38cfd6d
>>  - Merge master
>>    
>>    Change-Id: I5e1715fdb11305191fe7bf86cbfb7a6da446b3dc
>>  - Remove inlasm_isb define
>>    
>>    Change-Id: I2d0ef8a78292dac875f3f65d2253981cdb7a497a
>>  - AArch64: Add cross modify fence verification
>>  - AArch64: Use cross_modify_fence instead of maybe_isb
>>  - Split cross_modify_fence
>
> src/hotspot/share/runtime/orderAccess.hpp line 237:
> 
>> 235: // to the instruction code preceding the fence is not reordered w.r.t. any
>> 236: // memory accesses to instruction code subsequent to the fence in program order.
>> 237: // It  should be used in conjunction with safepointing to ensure that changes
> 
> This is rather misleading: the AArch64 needs the ISB for the instruction pipeline rather than the cache, which is invalidated by the IC IVAU broadcast. I suspect other processors work in the same way.
> The language in the AArch64 spec is better, IMO:
> "ensures that all instructions that come after the ISB instruction in program order are fetched from
> the cache or memory after the ISB instruction has completed"

This better?

// Finally, we define an "instruction_fence" operation, which ensures that all
// instructions that come after the ISB instruction in program order are fetched
// from the cache or memory after the ISB instruction has completed
// It should be used in conjunction with safepointing to ensure that changes
// to the instruction stream are seen on exit from a safepoint. Namely:
.....etc

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

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