Summary: | Safari browser fails to set boundaries to Wasm application memory | ||
---|---|---|---|
Product: | WebKit | Reporter: | jujjyl |
Component: | WebAssembly | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | anthony.bowker, fpizlo, justin_michaud, keith_miller, saam, webkit-bug-importer, ysuzuki |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 14 | ||
Hardware: | iPhone / iPad | ||
OS: | iOS 14 | ||
Bug Depends on: | 269777 | ||
Bug Blocks: |
Description
jujjyl
2021-02-07 10:37:13 PST
Yeah, I think we could give a better story here. There'
> Native compiled applications can be equipped on their own to handle memory
> allocation failures. I.e. when wasm memory.grow() fails, the calling
> malloc() for the compiled app will return 0, and the compiled code can
> manage it as it wishes.
Whoops accidentally submitted while typing my response. Anyway... I don't think a hard limit is really what we want or what a modern API for memory management would do. Rather, it would be better, IMO, if there was a memory warning event that fires as you approach high memory. But even that won't solve all the problems. For example, on iOS the OS is free to kill any process it wants for using too much memory (too much memory is decided based on system pressure not a fixed limit). Even on Mac it's hard to predict if a tab will go over it's memory budget since that ugh, I did it again... since that is based on the total web content process memory usage. *** This bug has been marked as a duplicate of bug 269937 *** |