RFR: 8254264: Remove redundant cross_modify_fence()

Alan Hayward github.com+4146708+a74nh at openjdk.java.net
Mon Oct 19 08:13:17 UTC 2020


On Fri, 16 Oct 2020 20:08:58 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Marked as reviewed by dholmes (Reviewer).
>
>> > And just to be clear any action that changes code such that a
>> > cross-modify-fence is needed by other threads, has to perform a global
>> > safepoint/handshake?
>> 
>> I'm not sure of that. But we added these fences for the case where the
>> code got patched during a safepoint. Maybe Robbin knows the answer.? : )
> 
> On x86 we have two compliant option according to the manual:
> 
> (* OPTION 1 *)
> Store modified code (as data) into code segment;
> Jump to new code or an intermediate location;
> Execute new code;
> 
> (* OPTION 2 *)
> Store modified code (as data) into code segment;
> Execute a serializing instruction; (* For example, CPUID instruction *)
> Execute new code;
> 
> - Code patching that happens outside a safepoint do options 1 and don't need CMF.
>   If CMF is needed on some arch, it must be encoded into the instruction stream while patching.
>   (whether this is really safe, thinking of spectre, is another story :) )
>   See e.g. NativeGeneralJump::replace_mt_safe()
> - Code patching that happens inside a safepoint do options 2 and need CMF.
>   We actual only need CMF for safepoints, but since we do not know why we were armed we must emit it.
>   So can be optimize by keeping track of the safepoint id and for which safepoint id we have emitted CMF for per java
>   thread.

I merged this patch together with https://github.com/openjdk/jdk/pull/428 (which makes AArch64 use cross modify fence)
and ran it on AArch64 with the "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on
the results of a much wider run.

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

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


More information about the hotspot-runtime-dev mailing list