1266393 - Is process isolation for iframes feasible to combat asm.js OOMing due to address space fragmentation ?

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, enhancement)

Description

[Jukka Jylänki]

Bug 1266389 highlights a particularly nasty problem that asm.js pages face on 32-bit browsers. 64-bit browsers are immune to this, but unfortunately a large portion of users have a 32-bit arch, not to mention the whole ARM world, where 64-bit is still in its infancy, so we can't quite just "wait it out" for the hardware to evolve.

Johnny Stenback has suggested that we could isolate iframes into their own processes to get a fresh address space for the asm.js pages to play with.

How would this look like? Is that something that would be feasible? How would it work in wasm? Would it require the sandbox property for the iframe, and what would the implications of that be for the Emscripten runtime?

Comment 1

[(not currently active) Ted Mielczarek]

This feels like a special-case of e10s. We do already have support for `<iframe remote>` in the codebase:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-remote
https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API

But it's only enabled on Firefox OS AFAIK. There's a check in the frame loader code that currently limits it to `<iframe mozbrowser>` or XUL elements:
https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/dom/base/nsFrameLoader.cpp#1797

I don't think that just changing that check will make it work though, c.f. bug 755320.

As an opt-in web feature this sounds pretty reasonable.

Comment 2

[(not currently active) Ted Mielczarek]

Also note that the e10s we're planning to ship initially won't really help here, since it's using a single content process for all web content. Multiple content processes would help, since each process gets its own address space, but that's not slated to ship at first (bug 1207306).

Comment 3

[Andrew McCreight [:mccr8]]

Chrome people have been looking into this for awhile, I think for security reasons:
  http://www.chromium.org/developers/design-documents/oop-iframes

Comment 4

[(no longer active)]

Out of process iframes is not something that can be implemented in a short amount of time.  We'd need to decide on a few things:

* Properly support more than one content process in Gecko.  AFAIK there's already some work happening in this regard for multi-content process e10s.
* One huge difficulty is that same origin iframes can be fully scripted from the container page.  So moving things such as sandboxed iframes or cross origin iframes to a separate process will be much easier.  AFAIK Chromium is looking at shipping OOP iframes for sandboxed iframes initially.
* The process model, as in, whether the process running the iframe will be the child of the parent process or something else.  That's how the b2g remote iframes were implemented.  We can hopefully reuse some of that code...

There's probably quite a few things I'm forgetting right now.

Comment 5

[Jukka Jylänki]

Michael Layzell has been implementing process isolation for large contiguous allocation requiring applications, and in https://bugzilla.mozilla.org/show_bug.cgi?id=1266389#c13 it was verified that this approach is effective. That is, by assigning a fresh address space to a page, Firefox doesn't trash the address space too badly before the page gets to execute, and if the page allocates its large contiguous memory enough early on, it will easily get to satisfy that allocation.

The proposed scheme doesn't operate on an iframe level, but on a per tab top level window level. If such a large allocation requiring page resides in an iframe, it will need assistance from the parent that contains the iframe to cooperate opting in. This is somewhat involved, but at this point not a critical restriction, since in practice sites that need this can cooperate their parent-> child iframe interactions to set this up.

Closing this as resolved, since we have positive confirmation that this scheme will work.