Also if you have a lot of data you use an ets table which is more or less an in-process but off-gc-heap key-value database.

Thanks, I've been wondering how Erlang does GC.

Of course, the cost is extra heap fragmentation.

In Erlang case, that is not so much of a problem as most allocated objects have essentially same size. On the other hand this causes another problem that GC's and allocators in Erlang VMs tend to have enormous overhead because most most GC'd objects are very small with sizes comparable to per-object GC overhead.

I joked once that in lisp, a vast majority of memory allocation are basically malloc(2). I wondered if it made fragmentation irrelevant.