Cancelling executions before OOMs

[Paul Harris]

Hi again,

Is there a nice way I could cancel a JS execution (eg raise an exception) from within eg the NearHeapCallback to avoid OOMs?

I'd rather if the script is consuming more RAM than expected, that it raises exceptions and unwinds rather than bombing out.

Thanks,
Paul

[Camillo Bruni]

Hi Paul,

You could try using v8::Isolate::TerminateExecution(). It's a best-effort approach to limit further JS execution and allocations.

cheers,

Camillo

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/9b1749b5-ccda-4a74-b846-d0347121c7fen%40googlegroups.com.

Camillo Bruni |

Software Engineer, V8 |

Google Germany GmbH |

Erika-Mann Str. 33, 80636 München

Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Diese E-Mail ist vertraulich. Falls Ssie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.  This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[dinf...@chromium.org]

Hi,

I don't think it's possible to do that from the near heap limit callback as our C++ code doesn't doesn't handle allocation failures gracefully. I believe on OOM you have to do something like: 1) extend the limit using that callback first and then 2) use Isolate::RequestTermination to cancel execution.

Hope that helps!

Cheers,

Dominik

[Paul Harris]

Ok thanks Dominik and Camillo.

I think RequestTermination can fail to actually interrupt execution if there is no additional callouts into the engine where it can throw something.  But better than nothing!

How big can the heap be these days?

I've seen mention of 2GB, 4GB, 8GB ... more?

[dinf...@chromium.org]

On Wednesday, March 22, 2023 at 2:47:15 PM UTC+1 harr...@gmail.com wrote:

Ok thanks Dominik and Camillo.

I think RequestTermination can fail to actually interrupt execution if there is no additional callouts into the engine where it can throw something.  But better than nothing!

I believe in such cases we could introduce additional checks to fix those issues. That would likely help other embedders as well (e.g. DevTools uses the same callback for a similar purpose).

 

How big can the heap be these days?

I've seen mention of 2GB, 4GB, 8GB ... more?

With ptr compression we are limited to 4GB but with full pointers the limit could be manually set to something that's larger than that.

[Paul Harris]

I read the blog posts about pointer compression and the advantages,

it seems like you get some performance benefit too?

The end goal is to set a maximum heap limit for a script execution (often short-lived),

and when breached, raise a nice "out of memory" error that an ordinary user could understand.

If the end users chooses, they can reexecute with a higher ceiling.

Sometimes a lot of RAM would be nice to use, but you really want to set some kind of expected limit

so all the memory isn't consumed by a runaway calculation.

With full pointers, that would involve turning off pointer compression,

but that would also disable cppgc_young_generation and a lot of the other cppgc features, right?

I think I saw the young-generation requires a cage which requires pointer compression?

You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/OeJ_DlMj3v8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/62d4fd80-7280-4f14-ba4a-a3eafdeb52f8n%40googlegroups.com.