[jetpack] Multi-process jetpack implementation API

[Benjamin Smedberg]

Ben Newman and I talked Wednesday afternoon, and came up with this
implementation proposal for multi-process jetpack, based on some of Josh
Matthews experimentation the past few months:

https://wiki.mozilla.org/Electrolysis/Jetpack

In particular, it's important to note how the jetpack implementation is
split up between two execution contexts: part of the jetpack implementation
runs in the browser, and part runs in the jetpack process. This seems to be
a fairly significant but necessary change from the way jetpack features are
currently written.

Also note that the CPOW wrappers which wrap a JS object across processes are
only used for pagemods (jetpack talking to content objects/nodes). CPOWs are
not used for jetpack/chrome communication.

This is still kinda-drafty and bnewman may make some additional edits, but I
wanted to post it in this state as an example of what we're thinking.

--BDS

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[johnjbarton]

According to
https://wiki.mozilla.org/Platform/2010-04-20
feedback is requested on this post.

Here's mine:

1) Why are you doing this? Creating a process for some parts of
jetpack then communicating with it is a huge investment of resources.
What value does this bring? Does that value really balance this
enormous complexity?

2) Where are you doing this? That is what infrastructure are you
integrating with? The reference page below links to info talking about
chrome and content processes but these are not part of the mozilla
platform. They seem to be proposed in only one place, the jetpack
description!

jjb

[Benjamin Smedberg]

On 4/21/10 11:10 AM, johnjbarton wrote:

> 1) Why are you doing this? Creating a process for some parts of
> jetpack then communicating with it is a huge investment of resources.
> What value does this bring? Does that value really balance this
> enormous complexity?

It is a longstanding desire of our platform that web pages and extensions
should not be able to block the browser UI. With the jetpack architecture
this is now possible, by moving the execution of the jetpack into its own
thread of execution.

We chose to do this with a process instead of a thread within the browser
process because it provides further isolation benefits: any crashes, CPU
usage, and memory-hogging behaviors of a jetpack-extension can be explicitly
known and presented to the user, and the user is given the option to kill
the jetpack-extension if it is misbehaving.

> 2) Where are you doing this? That is what infrastructure are you
> integrating with? The reference page below links to info talking about
> chrome and content processes but these are not part of the mozilla
> platform. They seem to be proposed in only one place, the jetpack
> description!

This functionality is built on top of the same IPDL/IPC infrastructure that
we have used for out-of-process plugins and are developing for multi-process
content.

[johnjbarton]

On Apr 21, 1:50 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> On 4/21/10 11:10 AM, johnjbarton wrote:
>
> > 1) Why are you doing this? Creating a process for some parts of
> > jetpack then communicating with it is a huge investment of resources.
> > What value does this bring? Does that value really balance this
> > enormous complexity?
>
> It is a longstanding desire of our platform that web pages and extensions
> should not be able to block the browser UI. With the jetpack architecture
> this is now possible, by moving the execution of the jetpack into its own
> thread of execution.
>
> We chose to do this with a process instead of a thread within the browser
> process because it provides further isolation benefits: any crashes, CPU
> usage, and memory-hogging behaviors of a jetpack-extension can be explicitly
> known and presented to the user, and the user is given the option to kill
> the jetpack-extension if it is misbehaving.

I gather then that each jetpack will get its own process? Or is there
a jetpack process for every content process? What part of the jetpack
will be in content process and what part not? The proposal says:
The jetpack JS itself will run in the content process.
and the rest of jetpacks are HTML and CSS overlaying the page, so what
is left?

Unlike plugins, jetpack will be hooked into the web page: killing the
process by user or accident will leave the page mods and hooks in
place with nothing to back them.

Was there discussion of alternative approaches which could result in
similar user values? In particular, users don't want to kill jetpacks,
they want jetpacks that work. (Most) jetpacks on firefox are not
likely to act like applications on operating systems: they modify the
content or the chrome or both. Collaborative testing and improved
application monitor tools might provide robust higher performance
application experiences than isolation and kill approaches.

>
> > 2) Where are you doing this? That is what infrastructure are you
> > integrating with? The reference page below links to info talking about
> > chrome and content processes but these are not part of the mozilla
> > platform. They seem to be proposed in only one place, the jetpack
> > description!
>
> This functionality is built on top of the same IPDL/IPC infrastructure that
> we have used for out-of-process plugins and are developing for multi-process
> content.

Ok, but the wiki page does not reference anything about that stuff,
which was my point.

[Benjamin Smedberg]

On 4/21/10 5:36 PM, johnjbarton wrote:

> I gather then that each jetpack will get its own process? Or is there
> a jetpack process for every content process? What part of the jetpack
> will be in content process and what part not? The proposal says:
> The jetpack JS itself will run in the content process.

Good catch, that was a bug. The jetpack JS will run in the jetpack process.

The current plan is to have each jetpack run in its own process, but its
possible that we could share a process for several jetpacks, if the startup
or memory overhead is too high. That can be measured/tuned, just as we've
done for plugins.

> Unlike plugins, jetpack will be hooked into the web page: killing the
> process by user or accident will leave the page mods and hooks in
> place with nothing to back them.

This is very similar to plugins, in fact. We don't expect users to kill
plugins or jetpacks under normal circumstances, but we would like to be able
to tell the user exactly how much CPU and memory a plugin or jetpack is
responsible for, and processes provide a simple an accurate measure.

> Was there discussion of alternative approaches which could result in
> similar user values? In particular, users don't want to kill jetpacks,
> they want jetpacks that work. (Most) jetpacks on firefox are not
> likely to act like applications on operating systems: they modify the
> content or the chrome or both. Collaborative testing and improved
> application monitor tools might provide robust higher performance
> application experiences than isolation and kill approaches.

Yes. It is clearly desirable that neither jetpacks nor content be able to
block the application UI. This can be accomplished with threads or with
processes. Given the way things are structured, processes are a more
practical solution than threads.

If you'd like to counter-propose some other mechanism, I'm happy to discuss
it, but this planning has been going on for a while and I really don't want
to start back at first-principles.

> Ok, but the wiki page does not reference anything about that stuff,
> which was my point.

This was describing the API that will available to JEP implementations, not
the underlying details about how that will be done.