bytecodealliance / bytecodealliance/endive
Redline: a mutable global reaching a second instance gets a copy
- Lingua principale
- Java
- Stelle
- 296
- Fork
- 21
- Merge medio
- 2g 4h
- PR unite (30g)
- 34
Descrizione
Redline shares a mutable global with the first instance that receives it. If the same global reaches a second instance, that instance gets a copy instead, so writes by one are not visible to the other. Every other execution mode shares it.
### Reproducing
Module `A` exports a mutable global, module `B` imports it and increments it, then `A` reads it back:
```
interpreter: exporter reads 101
redline: exporter reads 100
```
The same happens without any exporting module, by passing one host-created global to two instances: after each of them increments it, the host object reads `11` rather than `12`.
A global used by a single instance is shared correctly, and memories and tables are unaffected — they are reached through a pointer, so an importing machine simply uses the same one.
### Cause
`CtxBuffer.GLOBALS_PTR` points at one contiguous array of 8-byte slots per machine, indexed by global index, and compiled code reads a global with a single load:
```
globalsPtr = load_i64(ctxPtr, GLOBALS_PTR);
rawVal = load_i64(globalsPtr, globalIdx * 8);
```
A global's storage therefore has to live inside *that* machine's array at *that* module's index, and two machines cannot both hold the same global at their own index. `initializeImportGlobals` adopts a global that is not yet bound to any machine, and copies the value for one that is.
### Suggested fix
Add indirection for imported globals only. Their slot would hold a pointer to the real storage rather than the value, making `global.get` two loads:
```
slot = load_i64(globalsPtr, idx * 8);
val = load_i64(slot, 0);
```
Imports occupy indices `[0, importGlobalCount)`, so the compiler knows statically which globals need the extra load. Module-defined globals — the common case — keep the single-load fast path and cost nothing.
Touches `emitGlobalGet`/`emitGlobalSet` in `NativeEmitters`, the context layout, and `initializeImportGlobals` in both runners. It changes the compiled-code ABI, so it needs the full spec suite behind it.
### Impact
Marginal in practice: it needs two instances plus a shared *mutable* global. Not a regression — the copy predates the current import work, which fixed the single-instance case.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia con emitGlobalGet e emitGlobalSet in NativeEmitters, poi esamina il layout del contesto e initializeImportGlobals in entrambi i runner. Traccia come vengono rappresentati i global importati tra due istanze ed esegui l’intera suite di spec. Il lavoro è completato quando un global mutabile condiviso rimane condiviso tra le istanze senza modificare il fast path dei global definiti dal modulo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- java, wasm
- Ambito
- compilers
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Attiva
- Chiarezza
- Specificata chiaramente
- Idoneità per principianti
- 52/100