Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

shared objects: user space initialization safety

Ouverte
  • Quelque chose ne va pas ?
#119 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
wasm
Domaine
compilers

Piste de recherche

Aucun fichier, test ou point d’entrée d’implémentation n’est indiqué. Commencez par les sections Background et Problem, puis comparez les propositions release-fence et publish-instruction. La tâche est terminée lorsque le mécanisme de sécurité de l’initialisation et les trois questions de sémantique de publication listées ont été résolus dans la proposition.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
WebAssembly
Étoiles
100
Forks
7
Merge moyen
1 j 20 h
PR mergées (30 j)
1

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de WebAssembly/shared-everything-threads

Toutes les issues de WebAssembly/shared-everything-threads

Issues similaires

Plus d'issues Compilers

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.