3 ms·
> with GC you expect to run out of RAM and you expect the system to not just go down in screaming flames when that happens No, you don't. The main point of GC
by adwn 4y ago
> with GC you expect to run out of RAM and you expect the system to not just go down in screaming flames when that happens
No, you don't. The main point of GC is that you don't have to think about memory as much as with manual memory management. In fact, most GC languages don't even have an API to explicitly handle an out-of-memory condition: the program or thread will just crash or abort. With malloc(), you can at least properly react to allocation failures [1], which is crucial for hard real-time systems.
[1] Like storing the runtime state to flash and restarting the software.
- p_l 4y agoThat's not a property of malloc()/free()[1], that's a property of the runtime system which can be satisfied both in GC'ed languages and those with manual memory management. [1] To the point that porting code originating from Linux is rife with bugs when you run on systems that have the possibility of malloc() failing (99.9% setups of linux never report malloc() failure)
- kaba0 4y agoYou can only react to OOM when the OS gives you the necessary tools - under ordinary OSs malloc will not fail, even if it couldn’t actually allocate - actual allocation only happens when one writes to the location. But it doesn’t really apply to the topic at hand, just wanted to add.