turns out this was because the Runnable was calling a callback with a Collection. We where calling toArray on it (inside the callback). In android Studio I could see that it was not beeing released. Looks like anything thats alloacted within that callback is not released, since i also tested with an iterator. (though memory usaged is quite less)
So it was probably holding a reference to it.
This is still with the markingMode: full.
will test now with none

@patricklx, could you please attach a sample project illustrating the issue? Also did you get a chance to test with markingMode: none?

Hi @darind
I was able to create a sample app. I did test with markingMode: none, and it was working well.
But we are not yet ready to use it, since we would need additional testing with our custom plugins...

In this example you will be able to see that StringBuilder is leaking, so never released.

https://github.com/patricklx/ns-memory-leak
patricklx/ns-memory-leak@be91f12

@patricklx, thanks for the sample project. This is indeed a bug with markingMode: full which is now deprecated in favour of markingMode: none. One workaround is to manually release the memory associated with those objects using the __releaseNativeCounterpart method after you have finished using them:

const Test = my.Test.Test.extend({
    invoke(arg) {
        const val = arg.toString();
        console.log('invoked', val.length);

        // Manually release the native memory retained by the parameters:
        __releaseNativeCounterpart(arg);
    }
});

thanks, I already found that workaround. But it also does not release all other native object allocations in that callback... So, for every native function that returns a new object
Will you work on a fix or will you not fix this because of deprecation

We are not planning on making changes to the markingMode:full algorithm as it is now deprecated.