3 ms·

Speaking only for myself as ever: Handling out of memory errors is a hard problem. At the point when you can't allocate more memory you are busted in most lan

Speaking only for myself as ever: Handling out of memory errors is a hard problem. At the point when you can't allocate more memory you are busted in most languages. For example in C a slightly deeper function call depth can cause the stack to expand at any point. If that point coincides with you running out of memory then you are busted. No program can keep running with a broken stack. If V8 were capable of recovering from out-of-memory errors then you would still have to go through all of node and all the native libraries that it uses and check that they can handle any allocation failing. And if V8 handled out-of-memory errors with exceptions then you have two choices. Either make the exceptions uncatchable, in which case the JS program running in the server has no way to recover and is probably in an inconsistent state. Or make the exceptions catchable, in which case there is no guarantee that any memory will ever be freed up and you are back to square one. I think it's possible to make V8 more resistant to out of memory situations. I don't think it's possible to make it bulletproof, and I don't think there are many server apps that have this property. Do people run Java servers in such a way that they are often getting out of memory exceptions, recovering, and then continuing to serve? I don't think so. In practice the way most servers work is that you give them plenty of memory and you write your server app in such a way that it does not use unlimited memory. If there are non-out-of-memory errors that V8 is failing to recover from then these are bugs and should be reported. I can't think of any examples off-hand. As far as the other comments go they seem to assume that you will want to use a V8 context per connection. Node uses one V8 context for all connections, so the comments don't apply. Context creation has been speeded up a lot since the article was written, but this is only for the browser. Node doesn't need it.

JoachimSchipper 15y ago
You're being too clever - if you run out of memory, throw away the request and all associated resources and return "500: Internal server error". There are lots of reasons why this isn't perfect (if the OS overcommits memory, like Linux (typically?) does, it will have to kill you to avoid running out; if you need to use swap you're too slow to be useful; etc), but it's not impossible. node.js (one process for many requests) is a different model than the author is considering; no matter its (dis)advantages, integrating it into the server is not nearly as advantageous as for a process-per-request model (like mod_php).
- otterley 15y ago
  From a service perspective, I'd prefer to have the process crash and supervisor restart it. Returning HTTP/500 errors on memory allocation failures (which usually last until the process is restarted anyway) is likely to deny service to a larger number of users.
- swolchok 15y ago
  Overcommit seems to have changed somewhat since the "early days," as it's now heuristic. I ran into this once when I couldn't malloc 8 GB on a 64-bit machine because RAM + swap was less than 8 GB. http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting http://www.mjmwired.net/kernel/Documentation/vm/overcommit-a...
aaronblohowiak 15y ago
If you are using GBs of Heap space, GC pauses are going to make you cry before you worry about an OOM error. More, smaller processes are the way to go for a number of reasons (recovery is cheaper when you lose smaller things..)

JoachimSchipper 15y ago

You're being too clever - if you run out of memory, throw away the request and all associated resources and return "500: Internal server error". There are lots of reasons why this isn't perfect (if the OS overcommits memory, like Linux (typically?) does, it will have to kill you to avoid running out; if you need to use swap you're too slow to be useful; etc), but it's not impossible. node.js (one process for many requests) is a different model than the author is considering; no matter its (dis)advantages, integrating it into the server is not nearly as advantageous as for a process-per-request model (like mod_php).

otterley 15y ago
From a service perspective, I'd prefer to have the process crash and supervisor restart it. Returning HTTP/500 errors on memory allocation failures (which usually last until the process is restarted anyway) is likely to deny service to a larger number of users.
swolchok 15y ago
Overcommit seems to have changed somewhat since the "early days," as it's now heuristic. I ran into this once when I couldn't malloc 8 GB on a 64-bit machine because RAM + swap was less than 8 GB. http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting http://www.mjmwired.net/kernel/Documentation/vm/overcommit-a...

aaronblohowiak 15y ago

If you are using GBs of Heap space, GC pauses are going to make you cry before you worry about an OOM error. More, smaller processes are the way to go for a number of reasons (recovery is cheaper when you lose smaller things..)