Bug 221530 – Safari browser fails to set boundaries to Wasm application memory

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebAssembly

STR:

1. Visit the web site http://clb.confined.space/dump/mem_growth.html
2. Repeatedly click on Allocate Memory until all memory is exhausted.

The page offers a button to repeatedly allocate more memory for a WebAssembly application, until exhausting all possible available memory.
New pages are allocated with wasm memory.grow() operation.

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.

In Safari however, memory.grow() does not fail, but instead Safari kills/(crashes?)/reopens the whole tab without notice. This makes it impossible for application developers to manage memory usage: you can allocate memory up until some unknown amount, which will kill your whole application.

Instead, Safari should limit the amount that wasm memory.grow() can grow, and too large grows should just cap to the limit. This way applications can work against the limit, without risking the page to randomly crash.

Firefox currently has a limit of 2GB in mobile and desktop (which it can easily attain).
Chrome currently has a limit of 4GB on desktop, and due to their mobile browser being 32-bit and hitting address space fragmentation, a limitation of ~500-700MB in practice on mobile.

[Keith Miller]

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.

[Keith Miller]

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

[Keith Miller]

ugh, I did it again... since that is based on the total web content process memory usage.

[Radar WebKit Bug Importer]

<rdar://problem/74171413>

[Justin Michaud]

*** This bug has been marked as a duplicate of bug 269937 ***