1507759 - Print a sensible warning if failing to allocate a wasm memory due to virtual memory limits

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, enhancement, P3)

Description

[Lars T Hansen [:lth]]

I've run into questions on the web with people failing to allocate new wasm memories because we reserve a lot of virtual space per memory and they have very small per-process virtual memory limits by default, on the order of 8GB per process.  Here's Linux:

$ ulimit -v 8388608
$ dist/bin/js
js> var x = new WebAssembly.Memory({initial:1}) 
js> var y = new WebAssembly.Memory({initial:1}) 
uncaught exception: out of memory
(Unable to print stack trace)

In the situation where we fail to reserve a large wasm memory we should print a more reasonable error message than a generic OOM.  This need not even be system-specific, it could just be a better error message in response to the failed mmap in this case.

Comment 1

[Luke Wagner [:luke]]

Are you imagining that we do a detection of whether we're on a system which doesn't give processes much virtual memory by default and print a special/different warning/error?  That makes sense.

Or perhaps, before calling ReportOutOfMemory() during wasm memory creation, we could print a warning giving some simple diagnostics: how much we tried to reserve, and how much was reported available.  This does unfortunately mean some grotty per-OS #ifdefery.  Actually, we harvest a lot of that info as part of Telemetry and Breakpad; I wonder if there's a way to leverage that via hooks.  That also relates to the long-ago question of harvesting device characteristics for the baseline tiering decision.

Comment 2

[Lars T Hansen [:lth]]

(In reply to Luke Wagner [:luke] from comment #1)
> Are you imagining that we do a detection of whether we're on a system which
> doesn't give processes much virtual memory by default and print a
> special/different warning/error?  That makes sense.
> 
> Or perhaps, before calling ReportOutOfMemory() during wasm memory creation,
> we could print a warning giving some simple diagnostics: how much we tried
> to reserve, and how much was reported available.  This does unfortunately
> mean some grotty per-OS #ifdefery.  Actually, we harvest a lot of that info
> as part of Telemetry and Breakpad; I wonder if there's a way to leverage
> that via hooks.  That also relates to the long-ago question of harvesting
> device characteristics for the baseline tiering decision.

I was thinking more of the second approach for the quick-fix here, the VM allotment measurement being more a feature of bug 1507765 where we try to select a sane strategy for memory reservation.  But either/both would work.

Comment 3

[Lars T Hansen [:lth]]

Oh, and if the user is on a 32-bit build on a 64-bit OS (I think we only really support Windows for this case) we might also print some info about maybe upgrading the browser to 64-bit.  This seems relevant since we have ~40% users on 32-bit browsers but only ~15% on 32-bit OS.  There's a danger in doing this, though, since a user with 2GB RAM might find the browser experience to be worse with a 64-bit browser.

Comment 4

[Ryan Hunt [:rhunt]]

Attachment: Bug 1507759 - Wasm: Print slightly better warning message for failing to reserve huge memory. r?lth

There's a lot more sophisticated things we could do here, but hopefully this
improves the situation a little bit.

Comment 5

[Ryan Hunt [:rhunt]]

Attachment: Screen Shot 2019-08-15 at 5.09.03 PM.png

The attached image demonstrates the effects of this patch.

Comment 6

[Ryan Hunt [:rhunt]]

This patch is based on the work in bug 1518210. I could separate it and land it sooner, but I don't think it's high priority.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/55715c676a88
Wasm: Print slightly better warning message for failing to reserve huge memory. r=lth

Comment 8

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/55715c676a88