If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Document cookie getter can be slow with e10s

RESOLVED DUPLICATE of bug 1331680

Status

()

Core
Networking: Cookies
RESOLVED DUPLICATE of bug 1331680
a year ago
7 months ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox52 affected)

Details

(Whiteboard: [necko-next])

My browser was just being laggy, and profiling showed that a bunch of time in the content process was spent waiting on condvars with this stack:

js::jit::DoCallNativeGetter(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, JS::MutableHandle<JS::Value>)  (in XUL) + 110  [0x10ba3868e]
mozilla::dom::GenericBindingGetter(JSContext*, unsigned int, JS::Value*)  (in XUL) + 382  [0x109a2241e]
mozilla::dom::HTMLDocumentBinding::get_cookie(JSContext*, JS::Handle<JSObject*>, nsHTMLDocument*, JSJitGetterCallArgs)  (in XUL) + 163  [0x10997b363]
nsHTMLDocument::GetCookie(nsAString_internal&, mozilla::ErrorResult&)  (in XUL) + 292  [0x109cdd884]
mozilla::net::CookieServiceChild::GetCookieStringInternal(nsIURI*, nsIChannel*, char**, bool)  (in XUL) + 537  [0x107f9a959]
mozilla::net::PCookieServiceChild::SendGetCookieString(mozilla::ipc::URIParams const&, bool const&, bool const&, mozilla::NeckoOriginAttributes const&, nsCString*)  (in XUL) + 533  [0x1089a5415]
mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*)  (in XUL) + 1899  [0x10840f49b]
PR_WaitCondVar  (in libnss3.dylib) + 255  [0x107c7a94f]

That's a web page doing document.cookie, which calls into the cookie service, which starts doing sync IPC to the parent process...

I thought we cached cookies in the child process, at least to some extent.  If we don't, can we?
Whiteboard: [necko-next]

Updated

a year ago
See Also: → bug 1305380

Comment 1

11 months ago
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #0)
> I thought we cached cookies in the child process, at least to some extent. 
> If we don't, can we?

With multiple processes, this gets complicated since we'd have to invalidate the cache in all child processes whenever we change the cookie for any given domain. We held off on doing this because of that complexity but I guess we could implement a cache if we needed to.
> this gets complicated since we'd have to invalidate the cache in all child processes

That's true.  Do we need to do it synchronously, or can we do it async?  I guess we'd more or less have to do it synchronously so you can log in in one window and then in another one navigate to the same site and seem logged in?  But the sync bit would only need to be the call to the parent; once the parent receives the updated value and sends out async cache updates to the other processes it seems like we would be fine.  That's not worse, performance-wise than our current setup where any cookie write _or_ read is a sync call to the parent, right?
Being addressed in Bug 1331680, specific plan in Bug 1331680 Comment 14.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1331680
You need to log in before you can comment on or make changes to this bug.