bytecodealliance / bytecodealliance/endive

Redline: a mutable global reaching a second instance gets a copy

Abierto
#175 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Java
Estrellas
296
Forks
21
Merge medio
2 d 4 h
PR fusionados (30 d)
34

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Comienza con emitGlobalGet y emitGlobalSet en NativeEmitters; después inspecciona el diseño del contexto y initializeImportGlobals en ambos runners. Sigue cómo se representan los globals importados entre dos instancias y ejecuta la suite completa de specs. Se considera terminado cuando un global mutable compartido sigue estando compartido entre instancias sin cambiar la ruta rápida de los globals definidos por el módulo.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
java, wasm
Área
compilers
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Activo
Claridad
Bien especificado
Aptitud para principiantes
52/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.