Disallow atomic operations on unshared objects?

Inizia dall’invariante di progettazione e dalla restrizione sui riferimenti atomici citati in questa issue, quindi leggi la issue #97 e il commento collegato. Confronta le problematiche di alignment e generazione del codice per gli oggetti condivisi e non condivisi descritte qui. Il lavoro è completato quando la proposta contiene una decisione definitiva sulla possibilità di continuare a consentire le operazioni atomiche sugli oggetti non condivisi.

It was pointed out in issue #97 (see this comment) that one of the design invariants of the shared-every-thing-threads proposal is to allow engines to have different representations for shared and unshared references.

With that in mind, the current design

Atomic accesses to references are deliberately restricted to anyref, shared anyref, and their subtypes [...]

seems to be creating a decent implementation overhead for something with little to no value: atomic instructions on unshared objects.

For V8 we don't have different representations for shared and unshared objects, however, they live on different "heaps".
Now, to support atomic operations on i64 on all platforms, we need to emit atomic operations on all platforms for 64 bit fields.
On arm this requires 8-Byte-alignment of all i64 fields in wasm objects.

As a result, we align all i64 fields (and for simplicity double fields as well) in shared objects to have an offset that is a multiple of 8 bytes and then we additionally align the start address of any object to 8 bytes. We don't do this on unshared objects, however, and it is unclear if we'd want to do the same for unshared objects.

This means, for any atomic operation we need extra code to support this non-feature of unshared atomic operations: For struct.atomic.get etc. it's rather trivial, we just emit a struct.get for them as if it never was an atomic operation.

For struct.atomic.rmw.add and alike, this however means that for unshared atomic operations the implementation work is higher than supporting the shared atomic operations: For the shared part we can reuse the code generation used for the corresponding linear wasm instructions. For the unshared part, we need to write new code generation emitting patterns like struct.set($s, i32.add($a, struct.get($s))). While that doesn't contain anything new, it still is extra work and complexity and I'm wondering why we should even allow struct.atomic.rmw.add and all other atomic instructions on unshared objects, especially if engines might not even emit atomic operations for them?[^1]

@eqrion What's the situation for SpiderMonkey regarding shared vs. unshared objects? Do you already have some support for it for JS? What's the situation with heap object alignment? Are they always 8-byte-aligned?
(V8 emits ldrexd on Arch32 for atomic i64 loads which requires 8-byte-alignment, so pointer-size alignment is not sufficient in that case for us.)

[^1]: In theory we could emit more concise code on platforms that don't have these strict alignment requirements and then it could be argued that there is some benefit of using these atomic operations (similar to bulk operations) but that really isn't a goal of this proposal and it's questionable if there would be any community support for adding these instructions for unshared objects on its own (if it wasn't just included in this proposal).