Hi, The near heap limit callbacks are only called during GC. So I suspect what's happening here is that after a GC live heap objects fit nicely into the heap, so the GC doesn't invoke the callback. The GC doesn't really know about that quite large object allocation. I guess we could invoke that near heap limit callback on allocations as well, you can open an issue for that or provide a patch.
Dominik On Tuesday, August 16, 2022 at 8:36:46 PM UTC+2 tud...@gmail.com wrote: > Bringing this thread back -- I made a separate post about this ( > https://groups.google.com/g/v8-users/c/ZRjlM_hmdNk). > > I'm doing Array(1e7).fill(1) and the near heap limit callback doesn't get > called, and the heap limit is not obeyed. I set the heap limit to 4MiB and > the tiny little script happily allocates 40. > > I don't fully understand when the heap limit is actually checked -- it > doesn't seem to happen on every allocation (I suspect that it would be way > too expensive). > > I'm trying to RequestInterrupt from the near heap limit callback, and, > when interrupted, to TerminateExecution. I even tried doing this from a GC > epilogue instead of the near limit callback, but that doesn't get called > either (there is obviously no garbage from that tiny script). > > Thanks, > -Tudor. > > On Sunday, December 30, 2018 at 10:45:53 PM UTC-8 ma...@jsonar.com wrote: > >> Actually, no real recovery from such a condition needs to occur in v8 at >> all. If the process is genuinely out of memory, the OS will promptly kill >> it anyways.. all that needs to happen in v8 when the javascript environment >> tries to allocate more memory than the environment was told it had >> available is allow the allocation to succeed, but report an out of memory >> exception, and terminate the isolate. At the very least, it should be a >> compile-time option to have this behavior. >> >> >> On Sunday, December 30, 2018 at 11:13:20 AM UTC-8, Kenton Varda wrote: >>> >>> 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-u...@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-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 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/8c63dd29-befb-40b5-a666-a41d6eadbc0cn%40googlegroups.com.
