Intent to Implement and Ship: Large-Allocation Header

[Michael Layzell]

Summary:
Games implemented on the web platform using WASM or asm.js use large
contiguous blocks of allocated memory as their backing store for game
memory. For complex games, these allocations can be quite large, sometimes
as large as 1GB. In 64-bit builds, we have no problem finding a large
enough section of virtual memory that we can allocate a large contiguous
hunk. Unfortunately normal use of Firefox quickly fragments the smaller
address space of 32-bit Firefox, meaning that these complex games often
fail to run.

The Large-Allocation header is a hint header for a document. It tells the
browser that the web content in the to-be-loaded page is going to want to
perform a large contiguous memory allocation. In our current implementation
of this feature, we handle this hint by starting a dedicated process for
the to-be-loaded document, and loading the document inside of that process
instead. Further top-level navigations in that "Fresh Process" will cause
the process to be discarded, and the browsing context will shift back to
the primary content process.

We hope to ship this header alongside WASM in Firefox 52 to enable game
developers to develop more intense games on our web platform. More details
on the implementation and limitations of this header and our implementation
can be found in the linked bug.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1331083

Link to standard: This feature is non-standard

Platform coverage: Firefox Desktop with e10s enabled

Target release: Fx52

Preference behind which this is implemented:
dom.largeAllocationHeader.enabled

DevTools bug: none

Do other browser engines implement this?
No, we are in conversations with Chrome about them potentially also
recognizing this hint.

Tests: Added as part of the implementation

Security & Privacy Concerns: none

[Chris Peterson]

On 1/18/2017 12:21 PM, Michael Layzell wrote:
> Games implemented on the web platform using WASM or asm.js use large
> contiguous blocks of allocated memory as their backing store for game
> memory. For complex games, these allocations can be quite large, sometimes
> as large as 1GB. In 64-bit builds, we have no problem finding a large
> enough section of virtual memory that we can allocate a large contiguous
> hunk. Unfortunately normal use of Firefox quickly fragments the smaller
> address space of 32-bit Firefox, meaning that these complex games often
> fail to run.

If 64-bit Firefox doesn't have WASM OOM problems, will we still support
the Large-Allocation header on 64-bit?

[Martin Thomson]

On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell
<mic...@thelayzells.com> wrote:
> Security & Privacy Concerns: none

I doubt that this is true. You have provided a way for sites to gain
a whole process to themselves, on request. Denial of service seems
like something that would need to be considered if you intend to ship
this.

[Michael Layzell]

@Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default
2) which controls the maximum number of processes which may be allocated to
Large-Allocation processes. Any requests past that number
(firefox-globally) will not cause new processes to be created.

@Chris the Large-Allocation header acts as a hint. Currently I intend to
use dedicated processes on 64-bit as well as 32-bit, as there are some
minor differences in behavior due to there being multiple content processes
when loaded in the Large-Allocation process. In order to ensure that people
who are developing games don't run into these issues, I want to make them
(who will have 64-bit machines most likely) run into these issues before
reaching production. In the future, when we are shipping e10s-multi, we can
consider ignoring the large allocation hint on 64-bit architectures, as
there will be a much much lower chance of multiple content process only
differences affecting the program.

[Martin Thomson]

On Thu, Jan 19, 2017 at 10:17 AM, Michael Layzell
<mic...@thelayzells.com> wrote:
> @Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default
> 2) which controls the maximum number of processes which may be allocated to
> Large-Allocation processes. Any requests past that number (firefox-globally)
> will not cause new processes to be created.

That prevents unlimited spawning of processes, but doesn't stop a site
from blocking another one from getting a new process.

[Michael Layzell]

This is true, but I'm not sure how this is worse than other mechanisms
which can currently be used to deny other pages resources, such as
allocating and leaking large amounts of memory or pegging the event loop.

[Eric Rescorla]

On Wed, Jan 18, 2017 at 12:21 PM, Michael Layzell <mic...@thelayzells.com>
wrote:

> Summary:

> Games implemented on the web platform using WASM or asm.js use large
> contiguous blocks of allocated memory as their backing store for game
> memory. For complex games, these allocations can be quite large, sometimes
> as large as 1GB. In 64-bit builds, we have no problem finding a large
> enough section of virtual memory that we can allocate a large contiguous
> hunk. Unfortunately normal use of Firefox quickly fragments the smaller
> address space of 32-bit Firefox, meaning that these complex games often
> fail to run.
>

> The Large-Allocation header is a hint header for a document. It tells the
> browser that the web content in the to-be-loaded page is going to want to
> perform a large contiguous memory allocation. In our current implementation
> of this feature, we handle this hint by starting a dedicated process for
> the to-be-loaded document, and loading the document inside of that process
> instead. Further top-level navigations in that "Fresh Process" will cause
> the process to be discarded, and the browsing context will shift back to
> the primary content process.
>
> We hope to ship this header alongside WASM in Firefox 52 to enable game
> developers to develop more intense games on our web platform. More details
> on the implementation and limitations of this header and our implementation
> can be found in the linked bug.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1331083
>
> Link to standard: This feature is non-standard
>

Hmm... Do you intend to publish this with IANA using the procedures
specified in:
https://tools.ietf.org/html/rfc3864

DevTools bug: none
>
> Do other browser engines implement this?
> No, we are in conversations with Chrome about them potentially also
> recognizing this hint.
>
> Tests: Added as part of the implementation
>

> Security & Privacy Concerns: none
>

I share MT's concerns here. It seems like minimally there are DoS concerns
here, but
also potentially concerns about being able to force other Large Allocation
requesters
onto the same process (to the extent to which being on other processes is
valuable).

-Ekr

[tri...@mozilla.com]

On Wednesday, January 18, 2017 at 2:21:40 PM UTC-6, Michael Layzell wrote:
> Security & Privacy Concerns: none

Do we normally allow 1GB allocations? (I think the answer is 'we try and maybe crash if we can't' right?)

Allocating a continuous 1GB in a completely fresh process sounds like a great way to make a heap spray significantly more reliable. In a 32 bit process you'd have pretty good odds of hitting.

Even in a 64 bit process, I believe ASLR entropy on some platforms (older Windows perhaps) leaves something to be desired, in the 40-bit range or something. 1GB cuts that down pretty significantly.

So I'd definitely add this to the concerns, and probably a bit more serious than 'DOS'.

-tom

[joc...@chromium.org]

Hey,

a bunch of questions:

how will you handle synchronous scripting between that process and other frames from the same origin that aren't in that dedicated process?

Will it be possible for an iframe to send this header? What will happen then?

What will happen if a site requests a large allocation, but then runs out of address space/memory before it needs the allocation?

Will you somehow notify the site if you failed to allocate the requested memory?

After the first wasm program was run, will you return the memory? Will it stay reserved for future wasm programs on the same page?

best
-jochen

[Michael Layzell]

On Thu, Jan 19, 2017 at 3:58 AM, <joc...@chromium.org> wrote:

> Hey,
>
> a bunch of questions:
>
> how will you handle synchronous scripting between that process and other
> frames from the same origin that aren't in that dedicated process?
>

If there are other toplevel windows within the loading window's unit of
related browsing contexts, the Large-Allocation header will be ignored, and
a message will be printed to the console. There was no other easy way which
was in scope for the timeline of this project which didn't cause
web-visible side effects.

In an earlier version of the design, we considered severing these
synchronous connections but we decided on making the smaller web-compatible
change of simply ignoring the header in these problematic edge cases.

> Will it be possible for an iframe to send this header? What will happen
> then?
>

This header is ignored when it is seen while loading an iframe, like above.

> What will happen if a site requests a large allocation, but then runs out
> of address space/memory before it needs the allocation?
>

The current implementation of Large-Header ignores the size property of the
header. Instead, it always creates a new process, and loads the page into
it, performing no pre-allocation.

We were originally planning to support pre-allocation, but after testing we
determined that simply allocating a new process without the pre-allocation
would be sufficient to greatly improve allocation success rates.

In the future, we may decide to support pre-allocation. The design we were
considering would have involved allocating this memory at startup and
providing it to our JS engine. When a large allocation would be made that
reserved memory would be provided instead, with the remaining memory
returned to the OS.

We would also have a timer attached to the memory, as well as a memory
pressure listener, which if either of these events triggered before the
memory had been claimed, would free the allocation back to the OS.

When the website is done using the allocation, it would be returned to the
OS like usual.

> Will you somehow notify the site if you failed to allocate the requested
> memory?
>

The site will notice that it failed to allocate the requested memory when
it requests the memory, and the allocation fails. We don't provide any
other mechanism for notifying the website programmatically about
Large-Allocation status.

> After the first wasm program was run, will you return the memory? Will it
> stay reserved for future wasm programs on the same page?
>

See the above 2 answers.


>
> best
> -jochen
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>