Hacker News Reader

Comment by daemin | Hacker News Reader

One talking point I'd like to ask is:

For small short lived scripts and applications, do we even need to free any memory these days? For example you write a script which takes several seconds to execute, moves files, computes stuff with strings, etc. Should we really invest time and effort in the script interpreter to free the memory, where instead we can just exit normally and let the OS handle the clean up.

I would imagine this kind of paradigm could be much faster to run because of less runtime work being performed. The allocator used could also be a simple linear allocator which just returns the next free address and increments the pointer. If using multiple threads there could be one per thread.

What do people think of this?

View on HN

https://openjdk.java.net/jeps/318

Java epsilon gc is a no op gc

"exec() is the world's most efficient garbage collector." [1]

This idea is both worthy, and old.

[1] DJB, paraphrased, when responding to a criticism of the design of qmail, which rapidly forked very small processes which did a simple task and exit. Unable to find a link to the mailing list.

Hardly; it leaves file descriptors open that are not marked close-on-exec.

exit() is the world's most efficient garbage collector.

> For small short lived scripts and applications, do we even need to free any memory these days? ..we can just exit normally and let the OS handle the clean up.

That makes me think: why couldn't larger programs be composed of many such small, short-lived scripts/processes that give up all allocated memory upon exit?

I suppose there could be accumulated overhead for starting many such processes, and also the issue of allowing shared memory spaces that are explicitly not automatically freed. I'm way out of my depth in this line of thinking though, so, just speculating.

That’s essentially what happens if you use region-based allocation (aka arena allocation): https://en.wikipedia.org/wiki/Region-based_memory_management

This is basically the actor model. (many processes, sharing immutable data between them).

For short lived scripts and small programs you’re not expecting to need bleeding edge performance, so it doesn’t matter much either way.

Git reportedly[1] doesn't much bother with free()

[1] https://www.youtube.com/watch?v=dBSHLb1B8sw&t=115

This reminds me a bit of Erlang's "let it crash" philosophy.

Reply on news.ycombinator.com