830641 - Slim and fast: fork content processes from a prelaunched process

Status: RESOLVED DUPLICATE of bug 771765

(Core :: General, defect)

Description

[Cervantes Yu [:cyu] [:cervantes]]

Currently we launch the content processes by calling fork() and then execv(). This has some disadvantages:

1. Resources (e.g. JS components, images, etc.) cannot be shared among content processes.
2. Each content process is started from scratch, which takes longer time.

The current prelaunched process alleviates the app launch time, but doesn't help on reducing memory because it's fork()'d from the core process and it still execv()'d after fork().

We could improve on both 1. and 2. by changing the current process architecture:
* All processes fork() from a prelaunched process, like android's zygote process.
* Fork child processes from a child process.

The idea is to run the prelaunched process to some point and snapshot to make it the base of the processes. To launch an app, we just fork(), but not execv(), from this prelaunched process. After fork(), we need to recreate the states before it continues to work as an app:

- Recreate threads: To make more things shared between content processes, we may postpone the snapshot of the prelaunched child process. This means we may already have some threads running (e.g. the IO thread). These threads need to be recreated.
- Recreate file descriptors: FD pairs used in the event loops need to be recreated. FDs for IPC need to be created and passed to parent and child processes.

We also need to investigate how to take "snapshot" and resume in the prelaunched process. This will also bring changes to the monitoring of content processes.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This is also bug 771765, but I don't care which way we dup.

Comment 2

[Cervantes Yu [:cyu] [:cervantes]]

Track 771765 instead.