Eug*_*ene 11 java jvm jvm-hotspot compare-and-swap java-9
这个问题不是关于它们之间的区别 - 我知道什么是虚假故障以及为什么它会发生在LL/SC上.我的问题是,如果我使用的是intel x86并使用java-9(build 149),为什么它们的汇编代码有区别?
public class WeakVsNonWeak {
static jdk.internal.misc.Unsafe UNSAFE = jdk.internal.misc.Unsafe.getUnsafe();
public static void main(String[] args) throws NoSuchFieldException, SecurityException {
Holder h = new Holder();
h.setValue(33);
Class<?> holderClass = Holder.class;
long valueOffset = UNSAFE.objectFieldOffset(holderClass.getDeclaredField("value"));
int result = 0;
for (int i = 0; i < 30_000; ++i) {
result = strong(h, valueOffset);
}
System.out.println(result);
}
private static int strong(Holder h, long offset) {
int sum = 0;
for (int i = 33; i < 11_000; ++i) {
boolean result = UNSAFE.weakCompareAndSwapInt(h, offset, i, i + 1);
if (!result) {
sum++;
}
}
return sum;
}
public static class Holder {
private int value;
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
}
}
Run Code Online (Sandbox Code Playgroud)
运行:
java -XX:-TieredCompilation
-XX:CICompilerCount=1
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintIntrinsics
-XX:+PrintAssembly
--add-opens java.base/jdk.internal.misc=ALL-UNNAMED
WeakVsNonWeak
Run Code Online (Sandbox Code Playgroud)
compareAndSwapInt的输出(相关部分):
0x0000000109f0f4b8: movabs $0x111927c18,%rsi ; {metadata({method} {0x0000000111927c18} 'compareAndSwapInt' '(Ljava/lang/Object;JII)Z' in 'jdk/internal/misc/Unsafe')}
0x0000000109f0f4c2: mov %r15,%rdi
0x0000000109f0f4c5: test $0xf,%esp
0x0000000109f0f4cb: je 0x0000000109f0f4e3
0x0000000109f0f4d1: sub $0x8,%rsp
0x0000000109f0f4d5: callq 0x00000001098569d2 ; {runtime_call SharedRuntime::dtrace_method_entry(JavaThread*, Method*)}
0x0000000109f0f4da: add $0x8,%rsp
0x0000000109f0f4de: jmpq 0x0000000109f0f4e8
0x0000000109f0f4e3: callq 0x00000001098569d2 ; {runtime_call SharedRuntime::dtrace_method_entry(JavaThread*, Method*)}
0x0000000109f0f4e8: pop %r9
0x0000000109f0f4ea: pop %r8
0x0000000109f0f4ec: pop %rcx
0x0000000109f0f4ed: pop %rdx
0x0000000109f0f4ee: pop %rsi
0x0000000109f0f4ef: lea 0x210(%r15),%rdi
0x0000000109f0f4f6: movl $0x4,0x288(%r15)
0x0000000109f0f501: callq 0x00000001098fee40 ; {runtime_call Unsafe_CompareAndSwapInt(JNIEnv_*, _jobject*, _jobject*, long, int, int)}
0x0000000109f0f506: vzeroupper
0x0000000109f0f509: and $0xff,%eax
0x0000000109f0f50f: setne %al
0x0000000109f0f512: movl $0x5,0x288(%r15)
0x0000000109f0f51d: lock addl $0x0,-0x40(%rsp)
0x0000000109f0f523: cmpl $0x0,-0x3f04dd(%rip) # 0x0000000109b1f050
Run Code Online (Sandbox Code Playgroud)
weakCompareAndSwapInt的输出:
0x000000010b698840: sub $0x18,%rsp
0x0000010b698847: mov %rbp,0x10(%rsp)
0x000000010b69884c: mov %r8d,%eax
0x000000010b69884f: lock cmpxchg %r9d,(%rdx,%rcx,1)
0x000000010b698855: sete %r11b
0x000000010b698859: movzbl %r11b,%r11d ;*invokevirtual compareAndSwapInt {reexecute=0 rethrow=0 return_oop=0}
; - jdk.internal.misc.Unsafe::weakCompareAndSwapInt@7 (line 1369)
Run Code Online (Sandbox Code Playgroud)
到目前为止,我还没有足够多才能理解整个输出,但是肯定可以看到lock addl和lock cmpxchg之间的区别.
编辑 彼得的回答让我思考.让我们看看compareAndSwap是否是一个固有的调用:
-XX:+ PrintIntrinsics -XX:-PrintAssembly
@ 7 jdk.internal.misc.Unsafe::compareAndSwapInt (0 bytes) (intrinsic)
@ 20 jdk.internal.misc.Unsafe::weakCompareAndSwapInt (11 bytes) (intrinsic).
Run Code Online (Sandbox Code Playgroud)
然后使用/不运行示例两次:
-XX:DisableIntrinsic = _compareAndSwapInt
这有点奇怪,输出完全相同(相同的确切指令),唯一的区别是启用内在我得到这样的调用:
0x000000010c23e355: callq 0x00000001016569d2 ; {runtime_call SharedRuntime::dtrace_method_entry(JavaThread*, Method*)}
0x000000010c23e381: callq 0x00000001016fee40 ; {runtime_call Unsafe_CompareAndSwapInt(JNIEnv_*, _jobject*, _jobject*, long, int, int)}
Run Code Online (Sandbox Code Playgroud)
并且禁用:
0x00000001109322d5: callq 0x0000000105c569d2 ; {runtime_call _ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP6Method}
0x00000001109322e3: callq 0x0000000105c569d2 ; {runtime_call _ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP6Method}
Run Code Online (Sandbox Code Playgroud)
这是相当有趣的,内在代码不应该不同吗?
EDIT-2 the8472也很有意义.
锁ADDL是替代MFENCE是刷新StoreBuffer在x86,据我所知,它确实已经有知名度,而不是原子做.在此条目之前,是:
0x00000001133db6f6: movl $0x4,0x288(%r15)
0x00000001133db701: callq 0x00000001060fee40 ; {runtime_call Unsafe_CompareAndSwapInt(JNIEnv_*, _jobject*, _jobject*, long, int, int)}
0x00000001133db706: vzeroupper
0x00000001133db709: and $0xff,%eax
0x00000001133db70f: setne %al
0x00000001133db712: movl $0x5,0x288(%r15)
0x00000001133db71d: lock addl $0x0,-0x40(%rsp)
0x00000001133db723: cmpl $0x0,-0xd0bc6dd(%rip) # 0x000000010631f050
; {external_word}
Run Code Online (Sandbox Code Playgroud)
如果你看这里将委托给Atomic :: cmpxchg的另一个本机调用,它似乎是原子地进行交换.
为什么那不能代替直接锁定cmpxchg对我来说是一个谜.
TL; DR您正在查看装配输出中的错误位置.
两者compareAndSwapInt和weakCompareAndSwapInt 调用在x86-64上编译为完全相同的 ASM序列.但是,方法本身的编译方式不同(但通常并不重要).
源代码的定义compareAndSwapInt和weakCompareAndSwapInt在源代码中的定义是不同的.前者是本机方法,后者是Java方法.
@HotSpotIntrinsicCandidate
public final native boolean compareAndSwapInt(Object o, long offset,
int expected,
int x);
@HotSpotIntrinsicCandidate
public final boolean weakCompareAndSwapInt(Object o, long offset,
int expected,
int x) {
return compareAndSwapInt(o, offset, expected, x);
}
Run Code Online (Sandbox Code Playgroud)您所看到的是如何编译这些独立方法.本机方法编译为调用相应C函数的存根.但这不是在快速路径中运行的.
内在方法是那些调用被HotSpot特定的内联实现替换的方法.注:该电话将被替换,而不是方法本身.
如果查看WeakVsNonWeak.strong方法的汇编输出,您将看到它包含lock cmpxchg指令,无论是调用UNSAFE.compareAndSwapInt还是调用UNSAFE.weakCompareAndSwapInt.
0x000001bd76170c44: lock cmpxchg %ecx,(%r11)
0x000001bd76170c49: sete %r10b
0x000001bd76170c4d: movzbl %r10b,%r10d ;*invokevirtual compareAndSwapInt
; - WeakVsNonWeak::strong@25 (line 23)
; - WeakVsNonWeak::main@46 (line 14)
0x0000024f56af1097: lock cmpxchg %r11d,(%r8)
0x0000024f56af109c: sete %r10b
0x0000024f56af10a0: movzbl %r10b,%r10d ;*invokevirtual weakCompareAndSwapInt
; - WeakVsNonWeak::strong@25 (line 23)
; - WeakVsNonWeak::main@46 (line 14)
Run Code Online (Sandbox Code Playgroud)
一旦主方法被JIT编译,就不会直接调用独立版本的Unsafe.*方法.
在第一种情况下,正在使用本机方法。要么代码没有优化,要么不是内在的。
在第二种情况下,使用内部函数来内联所需的程序集,而不是调用 JNI 方法。虽然两种情况都会这样做,但我想不会。
| 归档时间: |
|
| 查看次数: |
830 次 |
| 最近记录: |