Yes, everyone gets what you're asking for. The problem is that V8's C++ code commonly allocates from the JavaScript heap. Every place where it does that, the C++ code would need a path to handle allocation failure. It's entirely possible to do, but it's a lot of work and hard to test.
-Kenton On Sun, Dec 30, 2018 at 8:47 AM markt via v8-users < v8-users@googlegroups.com> wrote: > 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> 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 >>> 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. >>> 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 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+unsubscr...@googlegroups.com. > 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.
