Baby’s First Garbage Collector (2013)

near-infinite virtual memory, yes, but there's practical limits to what the hardware can support.

After exhausting actual RAM, and swap - there's nowhere else to put things... so you'll crash anyway.

If you mean the jones/lins book, it's excellent[0]. Fully recommended to all.

[0] https://www.amazon.co.uk/gp/product/0471941484 I think there's a 2nd edition but I can't find it.

Basically, the memory management on modern computers with virtual memory has to self-impose some constraints to create internal pressure to clean up memory. The implementation may have the option to set some absolute maximum heap size. Or other parameters that set growth hurdles. The memory management tries to keep things within a given hurdle, but when it's obvious that more memory is needed, it changes to another hurdle: e.g. it allocates a new heap area from the OS with a big allocation.

There is a performance trade off there, because if lots of memory is available, but we tighten the belt anyway, the application may perform less well due to running garbage collection when it could have gotten away with allocating more external memory. On the other hand, the application is then less of a "pig" with regard to other things in the system.

Memory is a very finite resources actually. Pretty sure virtual memory and over allocation is a major issue with virtual machines and containerization nowadays.

Software preempt huge amount of memory because it's assumed to be unlimited free virtual memory. Except the software is running within a container or an OS, within a virtual machine, on a physical machine, that's running another hundreds things like that more or less isolated from one another.

While the application may be aware of what memory it's really using, the layers above may not be able to tell exactly what's used or sitting idle. It's a major challenge to estimate and distribute resources appropriately.

Sloppy, really.

[1] https://en.wikipedia.org/wiki/Directed_acyclic_graph

> Meanwhile, the simplest fix in the world - restart the process frequently - prevents memory leaks from accumulating, and requires no complicated tuning.

This is just a degenerate case of garbage collection, really.

I've seen many advocates of C++ claim that RAII [0] is a viable alternative paradigm to garbage collection or even a silver bullet to resource management in general. I find it's useful but I don't believe it's a silver bullet, yet my skill level is not high enough to come up with a counterargument, but you may find this approach interesting.

[0] https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

GC gives you memory safety in practice. It’s not possible to slip up in normal circumstances.

One of the Lisp machines of the 80's required you to save your work and reload so it would load in its more compact form. This was the first little while until they built the GC for this machine.

In a sane program without GC, you'll be freeing the memory when you don't need it any more, and your less talented colleagues will get it wrong.

Restarting the process frequently sounds like a very messy solution. It is not acceptable in all cases to restart the process frequently. For server software it is the rule that this is not acceptable. Also note that if your software is going to be used more it would need more frequent restarts. This will generally not make users happy. Maybe you could sometimes get away with starting a new process for every login. Memory usage will be higher in that case, though, perhaps unacceptably so. Also for software that is used on the desktop it would generally be frowned upon by the users.

I suppose it is possible to avoid garbage collection if you are willing to accept kind of old-style programming practices. You could have arrays of objects and when an object is no longer needed you don't deallocate it but allow it to be reused when another object of that kind is needed. I guess this would not lead to clearer code for most purposes. But, who knows, some people have been complaining about the lack of clarity in object oriented code.

I was going to upvote your comment and blame HN for not being able to upvote more than once.

Then you ruined it all with the last sentence...

Many reasons:

* It's much faster than malloc/free. a fragmented free is much much slower than a full stop-the-world major GC, and GC allocation is zero cost.

* it makes your program memory safe, memory safety is too hard to be left to the user.

* it makes your program run faster with a compacting collector (but not this trivial one). it does defragmentation, and puts together used arrays/strings, so that they often are on the same cache-line. typically 2x faster.

I'm not entirely sure why you're being downvoted, at the very least downvotes prove your original point... A lot of console games do this intentionally, and various console SDKs have special reboot modes to support it. It's falling out of favor in support of games that are architected for streaming, but they still kind of do the same thing internally (free a large chunk and start loading a new one from disk). It actually seems like a valid approach for back end services, especially if those services are mostly short lived and have quick start up times. It's a hard thing to do with a lot of the runtimes most web applications arr built with, but might be a valid approach with Rust or Go. I've heard people doing similar things with Erlang/OTP.