I'll just copy/paste the email I had in my drafts folder. On Wed, Feb 6, 2013 at 11:27 PM, Robert O'Callahan <[email protected]>wrote:
> We're going to want to add worker bindings for canvas (both 2D and WebGL). > Over time I expect we'll want worker versions of almost every popular DOM > API that doesn't actually require content/layout. We need to be able to > share code between worker and main-thread implementations as much as > possible. Right now a major blocker for that is that main-thread DOM APIs > require cycle collection and workers can't use cycle collection. So, what > are the prospects for supporting cycle collection in workers? (I'm talking > about independent cycle collectors for each thread, not any kind of > cross-thread CC.) > The DOM team is meeting in London this week. On Monday[0] we discussed the difficulty of adding new DOM APIs (e.g. IndexedDB, WebGL/Canvas, etc) to worker threads and we came up with a plan for fixing that. *The problem* There are two classes of problems involved in porting DOM APIs that already exist on the main thread to worker threads. 1. Dealing with the different ownership model on worker threads (no cycle collector, all owning references go through JS). 2. Dealing with things that are not available off the main thread (no necko, no gfx APIs, etc). There's obviously no general solution to the second class of problems. However, we believe that fixing the first class will allow us to implement DOM APIs on main and worker threads in the same class (with some branching depending on the thread à la IPDL). Currently on worker threads all owning references that could form a cycle with JS are traced by the JS GC. This means what would be C++-C++ edges on the main thread must instead be C++-"JSObject for C++" edges on worker threads. As currently implemented this requires a lot of manual JSAPI calls as well as a trace hook. It also has the serious disadvantage that mistakes result in exploitable use-after-frees, rather than unexploitable leaks. It also causes various problems with the WebIDL binding codegenerator in its current incarnation. *The plan* Therefore we've decided to discard the worker model in favor of a cycle collected model like we have on the main thread. Our plan is to do the following: 1. Port the cycle collector to non-main-threads. We will store the purple buffer in TLS. This also involves disconnecting the CC from parts of XPConnect (such as wrapper preservation). - khuey 2. Fix the current event dispatch code (content/events/) to work off the main thread by eliminating global state and any XPConnect dependencies. - smaug 3. Stand up nsDOMFileReader on worker threads to prove that we have working cycle collection/events on both main and worker threads. - khuey *FAQ* - *Does this mean cycle collected objects can be multithreaded?* No-ish. All cycle collected objects will belong to one and only one thread, and can only be AddRefed/Released on that thread. - *Will this require us to stop the world to CC? *No. Every thread that has cycle collection enabled will be cycle collected independently. - *Can an object on one thread own an object on another thread?* Not in a reference traced by cycle collection. Only cycles that remain entirely on a single thread can be collected. Cross thread cycles must still be broken manually. If declared to the cycle collector we will assert and die. - Kyle [0] At Turner's Last Stand _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
