Hi all, Sorry, I think my first message was confusing.
To be clear, in my case, my C++ process is nowhere near being out of memory. But, I'm configuring the V8 isolates I create with a low heap size, using v8::ResourceConstraints::set_max_old_space_size(). It's the V8 heap that is running out of memory. I'm well aware that writing C++ code that can recover from malloc() failure is basically impossible. But in my case, V8 is hitting a self-imposed limit on specifically the V8 heap. It seems like we should be able to find a hack to work around this. For example, I could live with a solution like: When V8's heap is exhausted, it calls the OOM callback. If that returns without terminating, then V8 doubles its own heap limit and continues. In this case, I would have my OOM callback call TerminateExecution() and arrange for the isolate to be discarded as soon as control returns back out of V8. It's fine if extra memory is allocated in the meantime as a stopgap to avoid aborting. Is there a way to accomplish something like this? If not, how hard would it be to add? >> For example, what if I compile with C++ exceptions enabled, and have my OOM >> handler throw an exception, hence unwinding the stack back to where I >> entered V8. Then, I promptly destroy the isolate. Would that work? > > No. It would end very badly. V8 is not exception-safe. To be clear about this suggestion: Obviously it's not going to be clean, but I was hoping to discuss what kind of bad things would actually be likely to happen. The isolate would be left in an inconsistent state, but if I'm deleting it anyway, how much does that matter? Small memory leaks would not be a big deal here, since I can periodically drain the process and start a new one to "fix" them. -Kenton On Wednesday, October 25, 2017 at 12:13:22 AM UTC-7, Andreas Rossberg wrote: > > To supplement Ben's answer: the reason why this was never a design goal is > that it is practically impossible to achieve. It is extremely difficult to > recover reliably from OOM in certain situations. AFAIK, no engine out there > is able to guarantee that. > > On 24 October 2017 at 22:44, Ben Noordhuis <[email protected] > <javascript:>> wrote: > >> On Tue, Oct 24, 2017 at 10:17 PM, 'Kenton Varda' via v8-users >> <[email protected] <javascript:>> wrote: >> > Hi v8-users, >> > >> > It appears that in some cases V8 will abort the process when it runs >> out of >> > heap space rather than throw a JS exception. The behavior can be >> overridden >> > by registering an OOM callback, but if that callback returns without >> > aborting, it seems V8 promptly crashes. >> > >> > It seems like some code paths are designed to handle OOM gracefully, but >> > others aren't. >> > >> > For my use case, it's pretty important that a malicious script cannot >> cause >> > the process to abort, since our processes are multi-tenant. Ideally OOM >> > would throw an exception, but terminating the isolate is also >> acceptable, as >> > long as other isolates can keep going. >> > >> > Is there any way to accomplish this? >> >> No. Graceful handling of OOM conditions is not one of V8's design goals. >> >> > For example, what if I compile with C++ exceptions enabled, and have my >> OOM >> > handler throw an exception, hence unwinding the stack back to where I >> > entered V8. Then, I promptly destroy the isolate. Would that work? >> >> No. It would end very badly. V8 is not exception-safe. >> >> > Or, is there some trick to making V8 less crashy on OOM, aside from >> going >> > through and fixing all the code paths that crash (which probably isn't >> > feasible for me)? >> >> No tricks, no. The best you can do is monitor memory usage and call >> `Isolate::TerminateExecution()` when it gets too high but that won't >> be 100% reliable; OOM conditions in C++ code will still be fatal. >> >> Probably not the answers you were hoping for but there it is. >> >> -- >> -- >> v8-users mailing list >> [email protected] <javascript:> >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
