compiler: fix compiledModule leak

[ncruces]

Fixes #1600.

I'm not 100% sure why this is needed, but it's being done as well in:

wazero/internal/engine/compiler/engine.go

Lines 495 to 508 in 1f8c908

	func (e *engine) Close() (err error) {
	e.mux.Lock()
	defer e.mux.Unlock()
	// Releasing the references to compiled codes including the memory-mapped machine codes.
	for i := range e.codes {
	for j := range e.codes[i].functions {
	e.codes[i].functions[j].parent = nil
	}
	}
	e.codes = nil
	return
	}

Somehow, not doing this prevents the releaseCompiledModule finalizer from running.

[ncruces]

This is obviously not the fix, but we clearly need to do more than #1535.

[achille-roussel]

I pushed a commit as a suggestion for a slightly different approach, but please feel free to revert or change it if we think this isn't the right approach.

The Go runtime cannot guarantee that finalizers will be run in the presence of cyclic references between objects, so I added an indirection layer to break the cycle between compiledModule and compiledFunction. A new compiledCode object is introduced that compiledModule and compiledFunction both reference, effectively removing the reference cycle between the two. The finalizer is still set on compiledModule, and is now called more reliably, which addresses the memory leak.

I've used a modified version of examples/allocation/zig/greet.go as suggested by @ncruces to reproduce the issue, adding debug statements to track memory usage (see https://gist.github.com/achille-roussel/ac529f1c10982b5c6dcd6239e72d828b), which shows stable memory usage at ~15MiB (tested on darwin/arm64).

[ncruces]

Any ideas on what to do about the failing test?
Otherwise your fix seems fine @achille-roussel! 👍

[mathetake]

excellent collaboration 🥇

[mathetake]

kudos to @ncruces and @achille-roussel