[Webkit-unassigned] [Bug 268816] iPad with 8 GB of RAM offers only 1.88 GB of RAM to a website via UInt8Array

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=268816

Ben Nham <nham at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nham at apple.com

--- Comment #10 from Ben Nham <nham at apple.com> ---
There are different memory limits in play for web content on iOS.

1. Webpages are loaded into a WebContent process. This process has an OS-defined memory limit. On iPhones, for most devices, the limit is 1.5GB (although if the system is not under memory pressure, the process may be able to exceed this limit). On iPad, the WebContent process has a higher memory limit, which differs by device. For an 8GB device, the limit will be in the 4GB+ range. I find it unlikely that these limits will change anytime soon, as they are chosen for user experience reasons (e.g. preventing a rogue webpage from causing all your background apps or background webpages from being killed on your phone).

2. Typed arrays, along with some other types of memory (like wasm memory) are allocated into a region called the Gigacage for security reasons. Currently the Gigacage supports 2GB of allocations on iOS. This has been the case for several years and we will probably not change this imminently, but we could possibly look into adjusting this if there are enough use cases that are running into this particular limit. (Incidentally, it is not as easy as just "increasing a limit" due to VA space layout reasons, but that's another discussion.)

So in the given example, your webpage is primarily allocating TypedArrays, which will be limited to ~2GB due to the gigacage restriction on iPads. On iPhones, you will likely be out-of-memory killed earlier by the OS at ~1.5GB of allocations. The Gigacage limit will almost never come in to play.

If you have some concrete examples of images in your editor that trigger the Gigacage limit described in (2), that would really help the JavaScriptCore team with evaluating how that limit should evolve in the future. But keep in mind that changing that particular limit will have no effect on the OS-level memory killer described in (1).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240313/19bdcb1a/attachment.htm>