638
edits
JSThreadsAndGC: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(→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). | ||
--> | |||