Issue with reloading compiled module about wazero

[mattjohnsonpint]

Also note that if instead of:

c2 := getCompiledModule(ctx, r)
c1.Close(ctx)
doAdd(ctx, r, c2)

I change the order and do this:

c1.Close(ctx)
c2 := getCompiledModule(ctx, r)
doAdd(ctx, r, c2)

Then it works - but there's a problem with that approach. In my real app I have these compiled modules saved in a map and accessed by an independent goroutine. So between closing c1 and loading c2, there's no compiled module ready to instantiate.

I think perhaps something in the runtime instance is stateful with regard to all modules? Thinking it might be the module name, I tried giving them different module names in their configurations - but with the same results.

[evacchi]

the underlying issue is that both compiled modules resolve to the same hash

wazero/internal/wasm/module.go

Lines 168 to 170 in 5c70d8b

	// ID is the sha256 value of the source wasm plus the configurations which affect the runtime representation of
	// Wasm binary. This is only used for caching.
	ID ModuleID

so when you close the first we are also deleting the cache entry:

wazero/internal/engine/compiler/engine_cache.go

Lines 18 to 26 in 99c057b

	e.mux.Lock()
	defer e.mux.Unlock()
	delete(e.codes, module.ID)
	// Note: we do not call e.Cache.Delete, as the lifetime of
	// the content is up to the implementation of extencache.Cache interface.
	}

a workaround is setting up a disk cache, this way when the key is deleted from the in-memory cache we will reload it from disk; e.g.:

	ctx := context.Background()
	cc, _ := wazero.NewCompilationCacheWithDir("/tmp/wazerocache")

	r := wazero.NewRuntimeWithConfig(ctx,
		wazero.NewRuntimeConfig().WithCompilationCache(cc))

this only occurs when you are closing and reloading a module with the same hash; if the module has been actually updated, then the hash should change, and deletion should not affect its cache entry.

[mathetake]

	// Works first time no problem
	c1 := getCompiledModule(ctx, r)
	doAdd(ctx, r, c1)

	// Fails second time because first module is closed - why?
	c2 := getCompiledModule(ctx, r)
	c1.Close(ctx) // I want to close c1, but keep c2 ready for use

yeah this patter simply doesn't make sense - why when the binary if the same you want to close the previous one? basically the variable c1 and c2 points to exactly the same objects and you essentially closed the compiled object.