RFR: 8254264: Remove redundant cross_modify_fence()

Patricio Chilano Mateo pchilanomate at openjdk.java.net
Mon Oct 19 13:56:11 UTC 2020


On Mon, 19 Oct 2020 08:10:25 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>>> > 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.

Thanks @robehn and @dholmes-ora for the reviews!

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

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


More information about the hotspot-runtime-dev mailing list