Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

shared objects: user space initialization safety

Aperta
  • Qualcosa non va?
#119 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
wasm
Ambito
compilers

Direzione di ricerca

Non vengono indicati file, test o punti di ingresso dell’implementazione. Inizia dalle sezioni Background e Problem, quindi confronta le proposte release-fence e publish-instruction. Il lavoro è completato quando il meccanismo di sicurezza dell’inizializzazione e le tre domande elencate sulla semantica della pubblicazione sono state risolte nella proposta.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Background

An important part of the memory model for shared GC objects will be that a thread can never observe uninitialized fields of an object allocated on another thread. For example, if I allocate a struct with (struct.new $s (i32.const 1)), no thread can ever read a 0 (or any other value) from that allocated struct unless the field is mutable and some other code writes that value into it.

In practice, this means implementations will have to do a release barrier at the end of shared object allocation. (A C++ release barrier technically does not have strong enough semantics, but it lowers to instructions that do have strong enough semantics on all architectures.)

Problem

Compilers for languages like Java will need to be able to provide similar initialization safety guarantees at the source language level. Java, for instance, guarantees that uninitialized final fields are never observed as long as the object being constructed is not leaked to other threads by its constructor.

Compilers could preserve this kind of initialization safety by constructing the WebAssembly object only at the end of the constructor and depending on WebAssembly's guarantees. Except that constructors (and the functions they call, including superclass constructors) generally need a real this object. So compilers could have a temporary this object used while calling constructors, then copy its fields to the "real" object at the end of the constructor. Except that this would be expensive and the temporary and real objects would be observably different, which would violate source language semantics.

So we need some other mechanism compilers can use to provide their own initialization safety.

Solutions

Release Fence

One option is to reuse the initialization safety formalism we will have in the memory model and reuse it in the semantics of WebAssembly release (and stronger) fences. Then producers can insert a release fence at the end of their constructors, just like WebAssembly engines will have to insert a release fence at the end of shared object allocation.

A downside of this approach is that there is nothing semantically tying the release fence to the particular object being published, so optimizers like Binaryen would not be able to remove the fence even in cases where they are able to optimize the constructor down to a single struct.new instruction. That means there would end up being two release fences at runtime; the engine's release fence at the end of struct.new followed by the user space release fence from the end of the optimized constructors. Beyond the extra runtime cost, the user space release fence would also unnecessarily prevent other possible instruction reorderings the optimizer might have wanted to do.

publish Instruction

A better approach would be to add a new instruction that provides the initialization safety publishing semantics for just a single object: publish.

instr := ... | publish

C |- publish : rt -> rt

publish pops an arbitrary reference value and ensures that any writes to the referenced value that happen-before the publish are visible to reads on any thread that are (happens-before or data-dependency or address-dependency)*-after the the publish. (At least approximately; we'll leave the precise formalism to @conrad-watt 😉) It pushes the same value back onto the stack, avoiding the need to use locals just to publish the value before doing something else with it.

Engines implement the publish with the same release fence they will use at the end of object allocation. Binaryen will be able to optimize out publish when there are no writes to the published object between its allocation and the publish because publish does not provide any guarantees already provided by the allocation in that case.

Open Questions

  1. What type does publish accept?
    • Right now the only mutable heap types are struct and array, so the most precise type we could accept would be (ref (shared eq)). But we would definitely want to accept a nullable reference for consistency with every other instruction that takes references, and it's harmless and future-proof to have it take arbitrary references.
  2. What does publish do when passed a null value?
    • Most instructions that take references trap on a null value, but there are exceptions such as extern conversions and nullable casts. It seems harmless to allow publish of nulls to do nothing without trapping.
  3. Should publish return its input?
    • This is unusual, but it is good for code size because otherwise the input would necessarily have to be local.teed to be used for anything else. The alternative would be to have it return nothing.
    • There is a question of how this should work for polymorphic stacks. When validation of publish pops bot, it should just push bot as well. There is precedence for this for e.g. select.

Edit log

  • Updated publish to push its operand back to the stack.
Lingua principale
WebAssembly
Stelle
98
Fork
7
Merge medio
1g 20h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di WebAssembly/shared-everything-threads

Tutte le issue di WebAssembly/shared-everything-threads

Issue simili

Altre issue su Compilers

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.