JSThreadsAndGC: Difference between revisions
(→Plans) |
No edit summary |
||
| Line 4: | Line 4: | ||
* Minor performance win from eliminating object locking | * 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 | '''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 | '''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. | 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 | 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 | The changes we need to make for single-tab GC will simultaneously make it | ||
| Line 18: | Line 18: | ||
==Plans== | ==Plans== | ||
Add API for creating a global object and associating it with a compartment. Use it in Gecko everywhere we create a global. Add API JS_GetObjectCompartment. | |||
Add assertions that there are no direct references across compartments, both at API boundaries and within the engine. | |||
Add API for creating objects that hold a single hard reference across compartments (use Proxy for this, I hope). | |||
Factor GC-related code into a class, js::GCHeap. Then divide it into two parts: the top-level GCHeap, which can do whole-runtime GC, and Subheaps that can be GC'd individually. | |||
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. | * 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. | * Use membranes to separate threads and GC heaps, as well as for security. This means making the membranes more robust, eliminating all leaks. | ||
| Line 47: | Line 62: | ||
==References== | ==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). | [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). | ||
--> | |||
Revision as of 23:24, 22 April 2010
Motivation
- 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
Add API for creating a global object and associating it with a compartment. Use it in Gecko everywhere we create a global. Add API JS_GetObjectCompartment.
Add assertions that there are no direct references across compartments, both at API boundaries and within the engine.
Add API for creating objects that hold a single hard reference across compartments (use Proxy for this, I hope).
Factor GC-related code into a class, js::GCHeap. Then divide it into two parts: the top-level GCHeap, which can do whole-runtime GC, and Subheaps that can be GC'd individually.
Make compartments the same thing as Subheaps.