WeakCompareAndSwap против сравнения с обменом

Этот вопрос касается не разницы между ними - я знаю, что такое ложный отказ и почему это происходит на LL/SC. Мой вопрос: если я нахожусь на Intel x86 и используя java-9 (сборка 149), почему существует разница между их ассемблерным кодом?

Я до сих пор не достаточно универсален, чтобы понять весь вывод, но определенно вижу разницу между блокировкой addl и блокировкой cmpxchg.

ИЗМЕНИТЬ Питер ответил, что я думаю. Посмотрим, будет ли compareAndSwap внутренним вызовом:

Это своего рода странно, вывод точно такой же (точные точные инструкции) с единственными отличиями, которые при включении intrinsic я получаю такие вызовы:

Это довольно интригует, не должен ли отличаться внутренний код?

lock addl является заменой mfence, которая, насколько мне известно, сбрасывает StoreBuffer на x86, и это действительно связано с видимостью, а не с атомарностью. Перед этой записью:

Если вы посмотрите здесь, будет делегироваться другому родному call к Atomic:: cmpxchg, который, по-видимому, выполняет обмен по-разному.

Почему это не является заменой прямой блокировки cmpxchg для меня загадка.

Ответы

Ответ 1

TL; DR Вы смотрите на неправильное место на выходе сборки.

Оба compareAndSwapInt и weakCompareAndSwapInt вызова скомпилированы для точно такой же последовательности ASM на x86-64. Однако методы сами компилируются по-разному (но это обычно не имеет значения).

Определение 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-скомпилирован, автономная версия методов Unsafe. * не будет вызываться напрямую.

Ответ 2

В первом случае используется собственный метод. Либо код не был оптимизирован, либо он не является внутренним.

Во втором случае внутренняя строка была использована для встраивания требуемой сборки, а не для вызова метода JNI. Я бы сделал, хотя оба дела сделали бы это, но я не думаю.

Ответ 3

Я считаю, что lock addl - это не атомный оператор, а реализация барьера в хранилище. атом находится в callq.

Поскольку вы уже регистрируетесь с помощью PrintIntrinsics, вы должны проверить, действительно ли он наследуется.