3 ms·

That some operating systems lie about resource commitments is no reason not to provide reasonable facilities for reacting to allocation failures. By doing so, y

That some operating systems lie about resource commitments is no reason not to provide reasonable facilities for reacting to allocation failures. By doing so, you make it harder to write well-behaved programs for systems that don't overcommit --- besides, no system overcommits address space, so malloc can always fail. It's true that even with reasonable allocation failure reporting on a non-overcommit system, you can use too much memory and make life unpleasant for users without actually seeing allocations fail. Bounding resource use is important regardless. That's an issue of good behavior, however. Even absent good behavior, programs should at least be robust. One of the reasons overcommit bothers me so much is that infects programming communities with the idea that resource consumption doesn't matter, since if you use too much, you're just going to get a SIGKILL anyway.

mondoshawan 11y ago
If you throw an exception, what would the resulting recovery mode even /be/, aside from clearing out unused memory (never mind that just finding all of your allocations is a nightmare in and of itself)? And how would this actually work in a non GC world where functions can allocate and free at any time -- ie, you are working on a team and can't know the state of every thread, task or chunk of code at once?
- quotemstr 11y ago
  > If you throw an exception, what would the resulting recovery mode even /be/ Unwind the stack and present an error message or take other appropriate action, just as we would for any other error. By unwinding the stack, we release owned resources, and some of those resources happen to be memory blocks. What makes memory so special? > just finding all of your allocations is a nightmare in and of itself Huh? In a non-GC system, if you can't find your allocations, you're leaking memory.
  - mondoshawan 11y ago
    My point about finding the allocations is actually a bit poorly put: not all parts of your program may be ready to release memory it has held without losing user data in the process. Memory is special insofar as it is a core resource that has so much contention that OOM situations may not be directly because of your application, and recovery may not even be possible without allocation. I'm slowly coming to realize my argumentative point is losing ground -- this is great! :-)

mondoshawan 11y ago

If you throw an exception, what would the resulting recovery mode even /be/, aside from clearing out unused memory (never mind that just finding all of your allocations is a nightmare in and of itself)? And how would this actually work in a non GC world where functions can allocate and free at any time -- ie, you are working on a team and can't know the state of every thread, task or chunk of code at once?

quotemstr 11y ago
> If you throw an exception, what would the resulting recovery mode even /be/ Unwind the stack and present an error message or take other appropriate action, just as we would for any other error. By unwinding the stack, we release owned resources, and some of those resources happen to be memory blocks. What makes memory so special? > just finding all of your allocations is a nightmare in and of itself Huh? In a non-GC system, if you can't find your allocations, you're leaking memory.
- mondoshawan 11y ago
  My point about finding the allocations is actually a bit poorly put: not all parts of your program may be ready to release memory it has held without losing user data in the process. Memory is special insofar as it is a core resource that has so much contention that OOM situations may not be directly because of your application, and recovery may not even be possible without allocation. I'm slowly coming to realize my argumentative point is losing ground -- this is great! :-)