Would wasmtime provide any advantage over <code class

There's one blocker for using wasmtime: <a class="issue-link js-issue-link" data-error

Thanks <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-u

Memory leaks (wasmtime vs wasmer) about go HOT 18 CLOSED

trealla-prolog commented on May 24, 2024

Memory leaks (wasmtime vs wasmer)

from go.

Comments (18)

enoperm commented on May 24, 2024 1

Sorry for "hijacking" this issue, though I do believe what I have observed is not entirely unrelated to the current state of wasmer-go

I have played around with the library, really like the concept, though I have ran into some issues with memory usage.

As an example, the code below demonstrates three separate issues:

Using a single engine instance for a large number of queries will cause memory usage to climb until around 7GiBs or so, at which point all subsquent queries are stuck - I suspect it has to do with the allocator, though I have not verified it. I'm pretty sure a leak is involved somewhere because I do not think any state should be retained from just querying for nl.
Using a single engine instance for a large number of queries that involve host-interop, will cause memory usage to climb until around 2GiBs, at which point I think the interop-related code uses an int32 to slice into WASM-allocated memory, resulting in a panic:

$ go run main.go -- --with-interop
2023/04/20 14:59:30
2023/04/20 15:00:53 trealla: query error: trealla: panic: runtime error: slice bounds out of range [-2130246640:]
exit status 1

The reason I described the issue here lies with this leak. In theory, it is not an issue if a WASM application leaks any memory, since it is very cheap to to just throw it away and allocate one with a fresh slate... except doing so will consume memory infinitely. The runtime does not seem to ever release the instantiated WASM modules/memory, and the result is a far larger, and faster memory leak than just using a persistent instance.

package main

import (
	"context"
	"fmt"
	"log"
	"math/rand"
	"os"
	"time"

	"github.com/trealla-prolog/go/trealla"
)

func newEngine(ctx context.Context) (trealla.Prolog, error) {
	engine, err := trealla.New()
	if err != nil {
		return nil, err
	}

	err = engine.Register(ctx, "invoke", 1, trealla.Predicate(func(pl trealla.Prolog, subquery trealla.Subquery, goal trealla.Term) trealla.Term {
		v := fmt.Sprintf("%v", rand.Float64())
		return trealla.Compound{
			Functor: "invoke",
			Args: []trealla.Term{
				trealla.Atom(v),
			},
		}
	}))
	return engine, err
}

func main() {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	engine, err := newEngine(ctx)
	if err != nil {
		log.Fatal(err)
	}

	log.Print()
	defer func() {
		recover()
		log.Print()
		os.Exit(2)
	}()

	getEngine := func() trealla.Prolog {
		return engine
	}

	// perhaps ugly, but suffices for testing
	query := `nl`
	for _, arg := range os.Args[1:] {
		switch arg {
		case "--with-interop":
			query = `invoke(A)`

		case "--with-new-instance":
			getEngine = func() trealla.Prolog {
				engine, _ := newEngine(ctx)
				return engine
			}
		}
	}

	for {
		func() {
			ctx, cancel := context.WithTimeout(ctx, 10*time.Second)
			defer cancel()
			engine := getEngine()
			doWork(ctx, query, engine)
		}()
	}
}

func doWork(ctx context.Context, query string, engine trealla.Prolog) {
	resultSet := engine.Query(ctx, query)
	defer resultSet.Close()

	for resultSet.Next(ctx) {
	}

	if err := resultSet.Err(); err != nil {
		log.Println(err)
		os.Exit(1)
	}
}

Since the alternative is getting stuck forever, I'm not entirely sure the int32 issue should be fixed just yet - I would personally prefer crashing and restarting to never getting anywhere at all, for one. But I think, assuming I'm not wrong about the source of the leak when each query is served by a new instance, a different WASM runtime might be more beneficial than it seems at first glance.

from go.

guregu commented on May 24, 2024 1

trealla-js looks fine so it shouldn't be a problem with Trealla itself. I think the issue here is we hold a global wasmer.Store which probably just infinitely accumulates memory. So we'd need to instantiate a new module for each Prolog to avoid that, but then we run into the wasmer-go bug you linked. I'll see about using a different library.

BTW the interop bug with the negative pointers should be fixed in the next release, but it can still run out of memory if hits 4GB. Not sure if any of the Go libraries support 64-bit WASM but if they do it should be possible to fix that.

from go.

enoperm commented on May 24, 2024 1

I have plugged in the wasmtime branch into the toy project where I initially detected the memory leak and I can confirm that it can now serve each request on a new Trealla instance just fine without any apparent leaks. ✔️

from go.