Clojurians Log v2
graalvm
The yamlscript binding devs are trying to figure out graalvm native image shared library isolates and isolatethreads, and how to manage them.
The rust implementor got 10 times improvement using the same isolate 10k times rather than creating a new one and tearing it down.
The function call being used returns a pointer to an allocated string buffer.
Afaict the buffers won't be freed until graal_tear_down_isolate(isolatethread) is called.
Anyone know much about how isolates work in this regard?
@borkdude 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 🙄
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