JSThreadsAndGC: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Motivation==
#REDIRECT [[JavaScript:SpiderMonkey:GC Futures]]
* More robust thread safety API
* Reduce GC pauses
* Minor performance win from eliminating object locking
 
'''Threading.''' In short, SM's support for sharing objects among threads has not gotten the maintenance attention it needs. It's accumulating bugs. At the same time, it is now widely acknowledged that shared-everything threads are a problematic programming model. Better ideas (like HTML5 Workers) are emerging. We need new JSAPI support for shared-nothing threads.
 
'''GC.''' At the same time our GC performance is not where we want it. There are
still direct optimization opportunities. Beyond that, we want to be able to perform GC on a single browser tab, for shorter pause times when only one tab is active.
 
What these two things have in common is that they both involve dividing the JSRuntime's object graph into separate, mostly-isolated ''compartments'', such that every object is in a compartment, and an ordinary object cannot have a direct reference to an object in a different compartment. (We will support special ''wrapper'' objects that provide transparent access to objects in other compartments.)
 
The changes we need to make for single-tab GC will simultaneously make it
easier to add assertions enforcing the new rules about sharing objects across
threads. Conveniently, in the browser, wrapper objects already exist in almost
all the right places--it's a critical security boundary in the browser, and the
wrappers impose various security policies.
 
==Plans==
 
These plans are limited to bugs that are part of the main central body of work to get us to per-tab GC, which we hope will dramatically reduce pause time.
 
{| width="80%" cellspacing="1" cellpadding="6" border="0"
|-
! scope="col" | Name
! scope="col" | Size (weeks)
! scope="col" | Assigned to (guess)
|-
| Benchmark automation
| 0.5
| jorendorff/gwagner
|-
| Compartments and wrappers API
| 0.5
| jorendorff
|-
| Compartment assertions
| 1
| jorendorff
|-
| GCSubheaps
| ?
| gwagner
|-
| MT wrappers
| 3
| jorendorff
|-
| Lock-free allocation and slot access
| 1
| jorendorff
|-
| Compartmental GC
| ?
| gwagner
|}
 
'''Benchmark automation''' — We need a way to turn a crank and get GC performance numbers: overall speed, length of longest pause, and total time spent in GC for several GC-intensive benchmarks. sayrer should get mail when we make these numbers move. This sort of data might as well be available via jsdbgapi.h in release builds. It won't be expensive to collect.
 
'''Compartments and wrappers API''' — Add API for creating a global object and associating it with a compartment. Use it in Gecko everywhere we create a global. Add minimal API for a special kind of object that is allowed to hold a strong reference across compartments (a wrapper object). Use it in XPConnect for our security wrappers.
 
'''Compartment assertions''' — Add assertions that there are no direct references across compartments, both at API boundaries and within the engine. Fix what breaks. In particular, wrappers and the structured clone algorithm will need to copy strings and doubles instead of passing them freely from one compartment to another.
 
'''GCSubheaps''' — Factor GC-related code into a class, js::GCHeap ({{bug|556324}}). Carve out a second class, GCSubheap, so that a single GCHeap can have several GCSubheaps, each of which handles its own set of VM pages from which individual GC things may be allocated. Give each compartment its own GCSubheap. Allocate every object, double, and string from the GCSubheap for the compartment where it will live.
 
'''MT wrappers''' — Implement an automatically-spreading membrane of proxy objects that allow one thread to access objects from another compartment that is running in another thread. There is some risk here because it's unclear how this should work regarding objects on the scope chain (global objects, Call and Block objects). See {{bug|558866}} comments 1-4.
 
'''Lock-free allocation and slot access''' — Remove locking from allocation paths. Remove scope locking everywhere. ({{bug|558866}})
 
'''Compartmental GC''' — Support collecting garbage in one GCSubheap without walking the rest of the graph ({{bug|558861}}).
 
Make compartments the same thing as Subheaps.
 
 
<!--
 
 
* Pursue opportunities to make GC faster without API changes. For example, string and object destruction (not finalizers) could be moved to the background thread.
* Use membranes to separate threads and GC heaps, as well as for security. This means making the membranes more robust, eliminating all leaks.
* Implement per-region garbage collection.
* Eventually: implement "worker modules" so addons have a non-broken way to use threads.
 
We have no immediate plans to implement cross-thread proxying. I'm not sure it would be sufficient for existing embeddings that share objects among threads; and it seems no one else needs it. The debugger needs to be able to touch objects across all threads, but proxying objects transparently across threads may not be the right answer there either. (jimb's first impression was that it is not.) I don't think enough is known about the new debugger's eventual design. By mid-March 2010 we'll know more.
 
There are 122 files using nsIThread in addons.mozilla.org. Locking wrappers are a possible solution for these guys, but it's likely they would ''still'' need source changes, in which case we should just encourage their authors to migrate to postMessage.
 
==Tasks==
* Igor: optimize GC and move finalization to background
* jorendorff: shell workers. tests for what we think the new contract should be.
* jorendorff: design whatever new JSAPI we need to support "regions"
* jorendorff: add assertions that test our assumption that objects aren't shared.
* jorendorff: ask bz about same-origin "regions" already implemented somewhere in Gecko ("window target algorithm")
* jorendorff: ask gwagner for his GC benchmarks so we have a baseline
* ???: review existing code that shares objects across threads
 
What is sharing objects across threads now?
* DocShell scripting cross-thread
* multithreaded xpcom
* UrlClassifier
* Personal Security Manager
 
(Proxy autoconfig is main-thread only.)
 
 
==References==
[http://www.adambarth.com/ Preventing Capability Leaks in Secure JavaScript Subsets]. Matthew Finifter, Joel Weinberger, and Adam Barth. To appear: Proc. of the 17th Network and Distributed System Security Symposium (NDSS 2010).
 
-->

Latest revision as of 22:39, 23 April 2010

Redirect to:

Retrieved from "https://wiki.mozilla.org/index.php?title=JSThreadsAndGC&oldid=218162"