[Webkit-unassigned] [Bug 99975] Remove ensureAuxiliaryContext

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=99975





--- Comment #6 from Dan Carney <dcarney at google.com>  2012-10-23 00:35:02 PST ---
(In reply to comment #5)
> (In reply to comment #3)
> > Definitely. I have no idea why auxilliary contexts exist.  They seem to me mostly like a good source of memory leaks, but I want some confirmation.
> 
> Jumping in with history:
> 
> The IndexedDB implementation used to have the Chromium "browser" process call via IPC into a "worker" process to do some IDB/V8 operations (given serialized script value and key path, return key; given SSV, key path and key, inject key and return new SSV). Note that this was stateless - SSV coming in, SSV or other value coming out immediately. This was creating a new V8 context on each call, which showed up as a CPU hotspot in profiling. We decided to cache the context and named it the "auxiliary context".
> 
> To eliminate the "worker" process and the IPC overhead, these operations were moved to the "renderer" - either performed eagerly (as soon as script performed some IDB operation, before the task made it to the browser) or lazily (the browser would asynchronously notify a specific renderer to initiate a task where it would fetch values to operate on). The auxiliary context may be unnecessary at this point, but when the refactoring (above) was done it was retained based on discussions at the time. (alecflett@ can say more here)

Okay, thanks for the clarification. That makes sense. The problem is that generated code in v8 expects a certain prototype chain for the context it is executing in, and the current setup doesn't have that consistently. Sometimes code that should be executing in the context of a DOMWindow is being executed in the context of the default object (the auxilliaryContext) and vice versa. If the SSV transformations really are all stateless, and they all execute in the auxilliaryContext, it would probably be the best solution in terms of performance. I think though, that my patch will not cause a lot of performance overhead, and will execute in the way that the rest of the system works, which has some readability benefits and is less prone to incomprehensible v8 crashes.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.