There’s a second trivial strategy that I wouldn’t recommend. It has the
unfortunate side effect of leaking memory. I seem to recall that it was
used by the Plan9 crew. Just allocate and never free! I guess that if
you squint hard enough, it kinda sorta looks like garbage collection,
without the collection part. Call it lazy garbage
collection? The trash will get taken out when the OOM killer comes.
But yes, real garbage collection for the win. It’s time-tested and
widely known.
chibicc also uses this memory management strategy:
Last but not least, chibicc allocates memory using calloc but never calls free. Allocated heap memory is not freed until the process exits. I’m sure that this memory management policy (or lack thereof) looks very odd, but it makes sense for short-lived programs such as compilers.
I recall there being companies that took this method for web servers as well - if you have multiple host one having to restart the server process doesn’t impact anything, and the cost of GC vs periodic restart (+ presumably more ram?) worked out in favour.
No, it’s quite easy.
There’s a second trivial strategy that I wouldn’t recommend. It has the unfortunate side effect of leaking memory. I seem to recall that it was used by the Plan9 crew. Just allocate and never free! I guess that if you squint hard enough, it kinda sorta looks like garbage collection, without the collection part. Call it lazy garbage collection? The trash will get taken out when the OOM killer comes.
But yes, real garbage collection for the win. It’s time-tested and widely known.
chibicc also uses this memory management strategy:
I recall there being companies that took this method for web servers as well - if you have multiple host one having to restart the server process doesn’t impact anything, and the cost of GC vs periodic restart (+ presumably more ram?) worked out in favour.