@U04V15CAJ I noticed in https://github.com/babashka/sci/blob/master/doc/libsci.md tutorial that you don't call graal_tear_down_isolate at all. I suspect it was to keep things succinct...

correct, if you want to do it properly you should call tear_down, but if it's a short lived CLI it's not really necessary

What I'm trying to figure out is how the thread heap grows for a long lived isolate

I think it's best to ask this in the GraalVM community slack, native-image channel

there is stuff to manage this, but I forgot what it was

👍 thanks, didn't know about that

I think they called it pinning, but that's for preventing something to be GC-ed

This article might also be useful, dunno: https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e

I guess pinning is for passing stuff to C and holding on to it via GC: https://www.graalvm.org/sdk/javadoc/index.html?org/graalvm/nativeimage/PinnedObject.html

lol, I didn't notice at first but the medium post was my starting point on this whole thing :face_with_rolling_eyes:

anyway, chatting with the graal slack peeps seems best

will head over there tomorrow

calling the buffer returning function in a loop didn't seem to grow ram usage

but I'm not great at benchmarking