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.
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
Aexports a mutable global, moduleBimports it and increments it, thenAreads it back: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
11rather than12.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_PTRpoints at one contiguous array of 8-byte slots per machine, indexed by global index, and compiled code reads a global with a single load: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.
initializeImportGlobalsadopts 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.gettwo loads: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/emitGlobalSetinNativeEmitters, the context layout, andinitializeImportGlobalsin 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.