weakCompareAndSwap VS比较并交换

这个问题是不是他们之间的区别 - 我知道虚假的失败是什么，为什么会发生在LL/SC。我的问题是如果我在intel x86上并使用java-9（build 149），为什么它们的汇编代码有区别？weakCompareAndSwap VS比较并交换

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; 
     } 
    } 
}

与运行：

输出compareAndSwapInt的
java -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics -XX:+PrintAssembly --add-opens java.base/jdk.internal.misc=ALL-UNNAMED WeakVsNonWeak

（相关部分）：
输出的weakCompareAndSwapInt
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

：

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::[email protected] (line 1369)

我远远不够的多才多艺，了解整个输出，但绝对可以看到锁ADDL和锁CMPXCHG之间的差异。

编辑彼得的回答让我想到了。让我们来看看比较并交换将是一个内在的呼叫：

-XX：+ PrintIntrinsics -XX：-PrintAssembly

@ 7 jdk.internal.misc.Unsafe::compareAndSwapInt (0 bytes) (intrinsic) @ 20 jdk.internal.misc.Unsafe::weakCompareAndSwapInt (11 bytes) (intrinsic).

然后用/运行两次的例子，而不：

-XX：DisableIntrinsic = _compareAndSwapInt

This is sor奇怪的T，输出是完全一样的（完全相同的指令），唯一的变化是与使内在我得到这样的电话：

0x000000010c23e355: callq 0x00000001016569d2 ; {runtime_call SharedRuntime::dtrace_method_entry(JavaThread*, Method*)} 0x000000010c23e381: callq 0x00000001016fee40 ; {runtime_call Unsafe_CompareAndSwapInt(JNIEnv_*, _jobject*, _jobject*, long, int, int)}

和残疾人：

0x00000001109322d5: callq 0x0000000105c569d2 ; {runtime_call _ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP6Method} 0x00000001109322e3: callq 0x0000000105c569d2 ; {runtime_call _ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP6Method}

这是相当有趣，不应该内在的代码是不同的？

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}

如果你看看here是将委托给另一本地call to Atomic:: cmpxchg这似乎是原子做掉。

为什么这不是直接替代锁cmpxchg是我的一个谜。

来源

2016-12-29 Eugene

与您的编辑和来自不同优化级别的众多汇编样本不太清楚你实际要求什么。 – the8472

因此，'sun.misc.Unsafe'仍然没有消失，但是移动到另一个包jdk.internal.misc中，证明它实际上不是一个兼容性问题，它使这个类保持活着？ – Holger

@Holger它没有移动，现在有两个版本。正如Shipilev所说，sun.misc.Unsafe将被删除 - 这次肯定。在sun.misc.Unsafe过去很有用的* other *地方有多个增强功能，现在已经过时（比如AtomicFieldUpdater）。他们甚至将释放/获取语义直接添加到不安全！ – Eugene

TL; DR您正在查看组件输出中的错误位置。

两个compareAndSwapInt和weakCompareAndSwapInt电话被编译到X86-64 完全相同的 ASM序列。然而，方法本身编译不同（但它通常不重要）。

在source code的的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); 
}

什么，你所看到的是这些独立方法如何编译。本地方法编译为调用相应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::[email protected] (line 23) 
               ; - WeakVsNonWeak::[email protected] (line 14) 

0x0000024f56af1097: lock cmpxchg %r11d,(%r8) 
0x0000024f56af109c: sete %r10b 
0x0000024f56af10a0: movzbl %r10b,%r10d  ;*invokevirtual weakCompareAndSwapInt 
               ; - WeakVsNonWeak::[email protected] (line 23) 
               ; - WeakVsNonWeak::[email protected] (line 14)

一旦主要方法是JIT编译的，不安全的独立版本。*方法不会直接调用。

来源

2017-01-16 21:51:39 apangin

你是对的：如果没有一些适当的经验（比如我），很难在整个荣耀中看到输出。你的解释太棒了！我在代码中看到并显示的是来自c2编译的* individual *方法输出，其中！=内部代码;一旦'strong'方法被编译，使用'UNSAFE.compareAndSwapInt'或'UNSAFE.weakCompareAndSwapInt'产生相同的输出意味着它们是内在代码是相同的。 – Eugene

在第一种情况下，正在使用本机方法。代码没有被优化，或者它不是内在的。

在第二种情况下，已经使用内在函数来内联所需的程序集，而不是调用JNI方法。我会虽然这两种情况下会这样做，但我猜不是。

来源

2016-12-29 14:56:35

确实你*很可能*是正确的，但我不知道为什么。查看编辑 – Eugene

@Eugene我同意它出现倒退。内在应该有mov，非内在应该有callq –

那不是重点。 * compareAndSwap内在*和* compareAndSwap非内在函数*仅在callq函数中有** **。我期待更多 – Eugene

我相信lock addl不是原子操作本身，而是store-load barrier implementation。原子发生在callq。

由于您已经使用PrintIntrinsics进行了日志记录，因此您应该检查它是否真正具有内在的含义。

来源

2016-12-29 15:33:32 the8472

的确你也是对的（见编辑-2），但它不回答主要问题。尽管如此，感谢您的意见。 – Eugene

weakCompareAndSwap VS比较并交换

回答

相关问题