Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Disallow atomic operations on unshared objects?

オープン
  • 何か問題がありますか？
#98 コメント 18 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
wasm
領域
compilers

調査の方向性

この issue で引用されている設計不変条件とアトミック参照の制約から始め、次に issue #97 と、そこからリンクされているコメントを読んでください。ここで説明されている共有オブジェクトと非共有オブジェクトの alignment およびコード生成に関する懸念を比較してください。提案で、非共有オブジェクトに対するアトミック操作を引き続き許可するかどうかについて決定が確定していれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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).

主要言語
WebAssembly
スター
97
フォーク
6
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WebAssembly/shared-everything-threads のほかの issue

WebAssembly/shared-everything-threads の issue をすべて見る

似ている issue

Compilers の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。