2 ms·

Yeah please don’t.. memory isn’t cheap when everybody does this. This behavior is the reason Java had such a bad time with sysops. Just make use of proper lib

Yeah please don’t.. memory isn’t cheap when everybody does this. This behavior is the reason Java had such a bad time with sysops. Just make use of proper libraries that will invalidate caches if needed, or simply refute to spawn new threads/actors/processes. I’d rather have some application halt/pause or simply crash if it ran out of memory.

zbentley 5y ago
Strongly disagree. First of all, we're talking about miniscule (usually Kb or less) amounts of memory here. Secondly, I'm not talking about over-allocating so programs can run in perpetuity; rather, I'm talking about keeping some small ballast around so cleanup and reporting can happen right before my program crashes/halts (think: the kind of code you'd put in atexit hooks). That's a better experience for operators and product maintainers than "your app disappeared without a trace because the OOM killer came for it" or "your app disappeared without a trace because its ENOMEM behavior was abort()". This is absolutely not why Java had/has a bad rap memory wise--that has more to do with a combination of code that allocates irresponsibly on the happy (not memory-error-anticipating) path, and the JVM's preference to preallocate as much as possible for every purpose, not just OOM handling. > Just make use of proper libraries that will invalidate caches if needed What if I've dumped every cache I can and I'm still getting allocation (or spawn, or whatever) errors because the system is out of memory? It's useful to have a contingency in place to turn out the lights room-by-room rather than cutting power to the whole building, as it were.
- jbverschoor 5y ago
  Misunderstood.. didn’t see the part that it’s just for handling it. I thought you were talking about just allocation a huge chinch of mem
  - zbentley 5y ago
    Nope, just crash ballast. I understand what you're condemning though: it's super regrettable when ordinary utilities, daemons, or desktop apps preallocate like like they're database servers on dedicated hardware.

zbentley 5y ago

Strongly disagree. First of all, we're talking about miniscule (usually Kb or less) amounts of memory here. Secondly, I'm not talking about over-allocating so programs can run in perpetuity; rather, I'm talking about keeping some small ballast around so cleanup and reporting can happen right before my program crashes/halts (think: the kind of code you'd put in atexit hooks). That's a better experience for operators and product maintainers than "your app disappeared without a trace because the OOM killer came for it" or "your app disappeared without a trace because its ENOMEM behavior was abort()". This is absolutely not why Java had/has a bad rap memory wise--that has more to do with a combination of code that allocates irresponsibly on the happy (not memory-error-anticipating) path, and the JVM's preference to preallocate as much as possible for every purpose, not just OOM handling. > Just make use of proper libraries that will invalidate caches if needed What if I've dumped every cache I can and I'm still getting allocation (or spawn, or whatever) errors because the system is out of memory? It's useful to have a contingency in place to turn out the lights room-by-room rather than cutting power to the whole building, as it were.

jbverschoor 5y ago
Misunderstood.. didn’t see the part that it’s just for handling it. I thought you were talking about just allocation a huge chinch of mem
- zbentley 5y ago
  Nope, just crash ballast. I understand what you're condemning though: it's super regrettable when ordinary utilities, daemons, or desktop apps preallocate like like they're database servers on dedicated hardware.