[atomics] Make IsLockFree handle 8 bytes

This cl makes IsLockFree return true for 8 bytes on x64 platforms.
The standard is unfortunately a bit vague on what exactly 'lock free' means.
As a result, we err on the side of caution. We can revisit this, but first
we need the specification to nail down exactly what 'lock free' in this
context.

Bug: v8:8100
Change-Id: I0a6099c6cb95a5581f3e71d0267857b88b4a2f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735592
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63099}

src/builtins/builtins-sharedarraybuffer.cc

@@ -22,8 +22,23 @@ namespace internal {
 // See builtins-arraybuffer.cc for implementations of
 // SharedArrayBuffer.prototye.byteLength and SharedArrayBuffer.prototype.slice
 
+// #sec-atomics.islockfree
 inline bool AtomicIsLockFree(double size) {
-  return size == 1 || size == 2 || size == 4;
+  // According to the standard, 1, 2, and 4 byte atomics are supposed to be
+  // 'lock free' on every platform. But what exactly does 'lock free' mean?
+  // For example, on x64 V8 uses a lock prefix to implement the semantics of
+  // many atomic operations. Is that considered a lock? Probably not.
+  //
+  // On the other hand, V8 emits a few instructions for some arm atomics which
+  // do appear to be a low level form of a spin lock. With an abundance of
+  // caution, we only claim to have 'true lock free' support for 8 byte sizes
+  // on x64 platforms. If people care about this function returning true, then
+  // we need to clarify exactly what 'lock free' means at the standard level.
+  bool is_lock_free = size == 1 || size == 2 || size == 4;
+#if V8_TARGET_ARCH_x64
+  is_lock_free |= size == 8;
+#endif
+  return is_lock_free;
 }
 
 // ES #sec-atomics.islockfree