Hacker News Reader

Comment by dmitrygr | Hacker News Reader

> Microvium on the other hand uses malloc and free to allocate when needed and free when not needed

on micros which lack an MMU (all of the ones allegedly targeted), this is how you fragment your memory to hell and eventually cause hard-to-debug crashes

View on HN

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.

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.

In a project like this, it seems it would be possible to combat fragmentation by simply moving data to be contiguous. The engine should be able to find all necessary pointers and update them. Yes, that's a slow operation, but for many usecases speed doesn't matter much.

Yep! That’s exactly what it does. It uses a compacting garbage collector.

Maybe it has support for typed arrays. Even for high level languages, usually on a micro, the main loop doesn't use any memory, or at least doesn't allocate.

Not splaining u, I am familiar with your work.

Reply on news.ycombinator.com