3 ms·
Can you articulate why it's a bad practice? If it works better than alternatives and it's documented, not really sure what the issue is. I don't think it's eve
by thebean11 6y ago
Can you articulate why it's a bad practice? If it works better than alternatives and it's documented, not really sure what the issue is.
I don't think it's even that uncommon. I believe some HFT firms run Java with a huge amount of RAM and GC disabled, and get around it by just rebooting the software occasionally.
To me writing software like that is fair game, I don't see the point in being dogmatic about "how things should be done".
- nitrogen 6y agoThis thread has a lot of branches, so I am just picking one for this general reply: I recall reading somewhere, years ago, that some OSes couldn't be relied upon to release unfreed memory when a process terminated. In those contexts, fastidious freeing would be important even in short-lived processes. In my own C code I tend to free everything so that I get a clean trace from Valgrind and don't risk masking legitimate bugs, but I typically write long-running daemons.
- pdimitar 6y agoMostly because I look at it from the angle of one-off / general purpose / CLI programs. If one such has to run for 10-30 seconds and its memory just keeps growing and growing with the idea of throwing it all away at the end and letting the OS handle it, it might become disruptive for other programs on the machine. For specialised apps and servers it's of course a perfectly good practice.
- jfkebwjsbx 6y agoIt is bad practice if your code cannot turn on deallocation for debugging purposes or library-like usage.