Closed Bug 626814 Opened 9 years ago Closed 1 year ago

Startup cache not available in content processes

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
fennec - ---

People

(Reporter: taras.mozilla, Assigned: taras.mozilla)

References

Details

Attachments

(1 file)

Currently we have one startup cache for firefox. Plugin-container can't make use of it.
You mean for content processes, right, not plugin proceses (which don't use XPCOM at all)?

What does this mean in practice? AFAIK almost nothing in the content process ought to be using things that typically live in the startup cache anyway.
153     rv = NS_GetSpecialDirectory("ProfLDS",
154                                 getter_AddRefs(file));
155     if (NS_FAILED(rv)) {
156       // return silently, this will fail in mochitests's xpcshell process.
157       return rv;
158     }

FWIW, I expect this is the current failure that's making it unavailable.
Yeah, you can't have the startup cache directly. If you need things from it, we need to send them from the chrome process. It's just not clear to me that we need it at all.
I believe taras filed this because of bug 623136.
(In reply to comment #4)
> I believe taras filed this because of bug 623136.
That prompted me to look at it, but I filed it because we load the following in the content process without startup cache

Get file:///home/taras/builds/fennec/dist/bin/components/DirectoryProvider.js in 23511
Get resource://gre/modules/XPCOMUtils.jsm in 23511
Get file:///home/taras/builds/fennec/dist/bin/components/BrowserStartup.js in 23511
Get file:///home/taras/builds/fennec/dist/bin/components/SessionStore.js in 23511
Get resource://gre/modules/Services.jsm in 23511
Get file:///home/taras/builds/fennec/dist/bin/components/Weave.js in 23511
Get file:///home/taras/builds/fennec/dist/bin/components/nsTryToClose.js in 23511
So the question is, is it a bug that these are being loaded in the content process? If so we can claim that startup cache is content-only.

If this is a supported use-case, then the easiest solution would be to give content own cache file.
I believe that none of the components you have listed should be loaded in the content process. And I believe that if none of the components are loaded, the modules won't be needed either (unless some message manager script loads them). Unfortunately I don't currently have a way to only register the components for the chrome process currently.
FWIW, I'm not opposed to making startup cache entries available via IPC (we probably should). I do strongly oppose trying to use the startup cache file from both processes. I'm just not sure if it's worth doing now, if we can work around the issue more simply.
(In reply to comment #8)
> FWIW, I'm not opposed to making startup cache entries available via IPC (we
> probably should). I do strongly oppose trying to use the startup cache file
> from both processes. I'm just not sure if it's worth doing now, if we can work
> around the issue more simply.

So what workaround do you propose?
For now, we could try completely disabling the JS component loader for content processes.
(In reply to comment #10)
> For now, we could try completely disabling the JS component loader for content
> processes.

filed bug 627148
Attached patch patchSplinter Review
one note about this patch, access to the the startup cache is slower from the content process than from the chrome process, presumably due to ipc overhead. To give an example, for my font cache patch in bug 623136, total font load time with 100% cache hit is ~6ms in the chrome process on my nexus one and 20-30ms on the content process.

The version of the patch on bug 623136 that uses the prefs system to store the font name cache sees 6ms font load times for both chrome and content process.
Assignee: nobody → blassey.bugs
Attachment #505833 - Flags: review?(tglek)
tracking-fennec: --- → ?
Assignee: blassey.bugs → tglek
Comment on attachment 505833 [details] [diff] [review]
patch

we decided to not pursue ipc in startup cache in this release cycle
Attachment #505833 - Flags: review?(tglek)
Summary: Startup cache busted in plugin-container → Startup cache not available in content processes
tracking-fennec: ? → 2.0-
Whiteboard: [fennec-4.1?]
Taras, do we want this?
tracking-fennec: - → 7+
This particular patch, no. mwu is adding readonly support for startup cache for content processes in bug 531398.
Whiteboard: [fennec-4.1?]
(In reply to comment #15)
> This particular patch, no. mwu is adding readonly support for startup cache
> for content processes in bug 531398.

Wrong bug# ?
tracking-fennec: 7+ → -
Don't think we want that anymore.
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.