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

Using FinalizationRegistry for ThreadBoundData

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

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

評価

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

調査の方向性

Issue で引用されている概要ノートから始め、その後、FinalizationRegistry、WeakMap、ThreadBoundData についての議論を確認してください。Issue にはファイル、テスト、エントリーポイントの指定がありません。完了とするには、提案されている MVP に対して共有 FinalizationRegistry キーを許容できるかどうかを文書化した判断が必要です。

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

説明

One idea that came up in verbal discussions of ThreadBoundData was the alternative of allowing shared objects as keys in a FinalizationRegistry, but not as keys in WeakMap. Opening this issue to continue this discussion.

With this, a shared object could hold an index to an unshared object stored in a thread specific table (instead of holding a ref to a ThreadBoundData). Then the toolchain could add the shared object into a finalization registry that would deallocate the unshared objects from the table when the shared object expires.

This would give languages 'strong' lifetimes for their shared-to-unshared references, while avoiding the need for engines to support marking all heaps together.

This would work because the unshared finalization registry only keeps alive an unshared callback, so there's no shared-to-unshared references for the engine to manage. The lifetime of the callback doesn't depend on the lifetime of the shared key. There is some coordination in the GC to notify finalization registries that a shared reference they contain has expired, but this could be done asynchronously with a notification or message from the shared GC.

WeakMap and ThreadBoundData (with strong behavior) are different because the lifetime of the unshared values depend on the lifetime of the shared keys. Liveness is transitive, so we'd have to be able to trace through all heaps to support this.

The downside of using finalization registry for ThreadBoundData would be that it could not collect arbitrary shared/unshared cycles. A cycle passing through shared and unshared objects using indices/finalization registry would not be visible to the GC and therefore not able to be broken.

I personally think that would be an acceptable tradeoff to deliver enough value with an MVP.

The only relevant note on this all that I found in the overview was:

An intermediate behavior would be the strong behavior but without cross-heap cycle collection. This is as expressive as the weak behavior if we were to hypothetically augment it by allowing shared objects to be keys in FinalizationRegistry but not WeakMap (which would be too inconsistent for us to actually ship). The FinalizationRegistry would be able to automatically manage the lifetimes of rooted unshared objects as long as they do not cyclically keep the shared objects that refer to them alive.

I would argue this is not necessarily inconsistent behavior. As noted above, FR and WM have different implementation characteristics, it seems reasonable for them to have different restrictions. I be curious to hear why they must accept the same set of values as keys.

cc @lukewagner who originally brought up this idea.

主要言語
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 を短くまとめたダイジェスト。