Hacker News Reader

Comment by dmitrygr | Hacker News Reader

The Malloc/free thing is weirder and weirder the more I think about it. Js is a managed language. Instead of pointers you can use handles (double printers, via an indirection Table) and with a custom allocator you could compact the heap and thus avoid fragmentation. (This is what I remember doing in my tiny Java vm a decade ago). Malloc/free actively preclude this and force the fragmentation on you.

View on HN

Microvium does use a compacting heap, something similar to a semi-space collector except that it can free up the unused "space". Have a look for some of the details: https://coder-mike.com/blog/2020/07/08/new-garbage-collector...

But the malloc/free thing referenced in the article is mainly about the stack space and core registers, which would just be wasting space if the VM was idle.

So what's the allocation pattern like (regarding malloc/free)? Last time I used scripting language in constrained environments it was Duktape and one of the issues was wildly varying allocations ranging from few bytes to kilobytes depending on usage. We ended up implementing TLSF like allocator which worked well in the end.

It calls malloc once or twice when you resume a snapshot. The first malloc includes core persistent state (e.g. memory stats counters, etc), and global variables in the script. If there is any heap in the snapshot, the second malloc is for the initial heap.

Then it calls malloc when you call from C in JS -- about 300B by default. This is to allocate the core registers and virtual stack. It frees it when the JS has fully completed and control returns to the host.

Then it also calls malloc each time it runs out of space in the managed heap and needs to expand. By default these will be 256B chunks. If you use a lot of heap space, maybe you want to increase this chunk size to reduce overhead here.

And it calls malloc about once or twice each time there is a GC collection, regardless of heap size.

Reply on news.ycombinator.com