I was not suggesting that v8 be designed to recover from situations where the native process has actually run out of all available memory, I am suggesting that v8 should be designed to recover (in some way that does not terminate the process) from situations where the javascript code that may be executing is consuming more memory than what the javascript code was permitted to use, which may be *FAR* less than the amount of memory that is actually available on the computer. The isolate that contains the badly behaved javascript code should be marked as having an irrecoverable error associated with it, and any further attempts to manipulate the isolate should behave as if that isolate has already been terminated. This irrecoverable error could be detected by the embedder when it resumes control, and the embedder can recover from this situation with respect to the rest of its native process in its own way. The isolate would remain unusable, but the native process would not crash. Eventually, the embedder would have to simply dispose of the isolate, and start over if desired with a new one, if more javascript code execution is desired, reporting the out of memory situation as applicable to the situation, perhaps by blacklisting the script which caused the behavior until it can be manually vettted to ensure that the situation does not happen again.
My point remains, if a process is genuinely consuming too much memory, the operating system will unceremoniously kill the process anyways. It is redundant at best to deliberately put this kind of logic into v8, and at worst renders v8 unusable for many situations. On Tuesday, December 4, 2018 at 1:01:36 PM UTC-8, Kenton Varda wrote: > > On Tue, Dec 4, 2018 at 12:40 PM markt via v8-users < > v8-u...@googlegroups.com <javascript:>> wrote: > >> To be perfectly honest, this seems rather pointless to terminate the >> process in this way. >> >> If, in fact, a process were legitimately using too much memory, the >> underlying operating system should be entirely capable of killing it >> anyways. Having v8 do so of its own accord instead of simply returning an >> error condition that could be detected by an embedded application as an out >> of memory condition with the v8 engine seems superfluous at best, and >> completely unusable for many purposes at worst. >> > > I don't think that's the point. The point is that many code paths in V8 > are not prepared to handle memory allocation failures. Gracefully handling > allocation errors often requires significantly more code, tests, and > general engineering effort, which would be totally wasted for Chrome's use > case since Chrome will just terminate the process anyway. > > Personally I would much prefer if V8 did handle these cases but it makes > plenty of sense why they don't. > > -Kenton > > >> >> >> >> On Tuesday, October 24, 2017 at 1:44:59 PM UTC-7, Ben Noordhuis wrote: >>> >>> On Tue, Oct 24, 2017 at 10:17 PM, 'Kenton Varda' via v8-users >>> <v8-u...@googlegroups.com> 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 >> v8-u...@googlegroups.com <javascript:> >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "v8-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/v8-users/vKn1hVs8KNQ/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> v8-users+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- -- v8-users mailing list v8-users@googlegroups.com 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 v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
