Continuous memory growth in jco component · StarlingMonkey

Hello I have a very simple question about jco components. I have a simple wasm component compiled from the following js

export const handlerInterface = {
    handleevent(event) {
        return event;
    }
};

using jco componentize handler.js --wit ../component.wit -d all -o handler.wasm
with the following wit

package test:test;

interface handler-interface {
    record request {
        uri: string
    }

    handleevent: func(event: request) -> request;
}

world handler-world {
    export handler-interface;
}

I'm using wasmtime to call the handleevent guest function on the component in an infinite loop. It seems that RES memory of the process is constantly increasing over time. Is this expected with components compiled with jco? I don't see the same memory usage using cargo-component for example. Maybe it's expected with a javascript runtime and JIT or whatnot, but it would seem weird to me? Any help appreciated.

GitHub - ludfjig/jco-vs-cargo-component-memory-usage: Compares memory usage of jco vs cargo-component

Compares memory usage of jco vs cargo-component. Contribute to ludfjig/jco-vs-cargo-component-memory-usage development by creating an account on GitHub.

Tomasz Andrzejak (Aug 01 2025 at 06:11):

Hey Ludvig, thank you for the repro. No, this is not expected behavior. Unfortunately, StarlingMonkey hasn't been thoroughly tested for long-running use cases, so it's entirely possible that we have a memory leak somewhere. I would start by ensuring you're using the latest jco version, as there were some memory-related fixes in the most recent StarlingMonkey release, and I will have a look at your example to see if I'm able to track the leak.

Tomasz Andrzejak (Aug 01 2025 at 07:03):

To provide additional context: I would also say it's normal to see memory usage fluctuations in JS components due to garbage collection. The GC will allow memory to accumulate temporarily before triggering a collection that should eventually bring memory usage down, but FWIU what you're observing is linear increase until oom?

Ludvig Liljenberg (Aug 01 2025 at 17:17):

Thanks for the reply. Indeed memory increases linearly with no signs of stabilizing. I tried most recent jco version as well, but unfortunately I'm still seeing it

Victor Adossi (Aug 04 2025 at 09:36):

Hey @Ludvig Liljenberg would you mind filing an issue about this? The most appropriate place might be either componentize-js or StarlingMonkey , but I'd love to track this so that we can be sure it's fixed long-term.

I mention this because I originally thought this might be a case of this bug from Jco, but it doesn't seem to be, so I'm thinking we should make sure it's tracked.

jco componentize out of memory · Issue #568 · bytecodealliance/jco

Hey all, thanks for the cool project! I've been following various talks in the space for the last year and am really excited to be trying out some stuff! Background I'm working in a Rust codebase t...

Notification Bot (Aug 05 2025 at 20:12):

Ludvig Liljenberg (Aug 07 2025 at 18:39):

Continuous memory growth in jco component · Issue #279 · bytecodealliance/ComponentizeJS

I have a simple wasm component compiled from the following js export const handlerInterface = { handleevent(event) { return event; } }; using jco componentize handler.js --wit ../component.wit -d a...

Ludvig Liljenberg (Sep 16 2025 at 00:10):

Fix memory leak in call() retptr allocation by ludfjig · Pull Request #295 · bytecodealliance/ComponentizeJS

JavaScript components leak memory when returning non-primitive types (strings, objects, arrays, etc.). Cause Return pointer allocation used JS_realloc which bypasses memory tracking, so allocations...

Stream: StarlingMonkey

Topic: Continuous memory growth in jco component

Ludvig Liljenberg (Jul 31 2025 at 23:33):