638
edits
JSThreadsAndGC: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Motivation | ==Motivation== | ||
* | * More robust thread safety API | ||
* | * Reduce GC pauses | ||
* | * Minor performance win from eliminating object locking | ||
Plans | '''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. I'll propose something in this newsgroup later this week. | ||
'''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 "regions", such that every object is in a region, and an ordinary object cannot have a direct reference to an object in a different region. (We will support special "wrapper" objects that provide transparent access to objects in other regions.) | |||
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== | |||
* 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 14: | Line 27: | ||
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. | 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 | ==Tasks== | ||
* Igor: optimize GC and move finalization to background | * Igor: optimize GC and move finalization to background | ||
* jorendorff: shell workers. tests for what we think the new contract should be. | * jorendorff: shell workers. tests for what we think the new contract should be. | ||