638
edits
JavaScript:SpiderMonkey:GC Futures: Difference between revisions
JavaScript:SpiderMonkey:GC Futures (view source)
Revision as of 01:10, 24 April 2010
, 24 April 2010→Compartments and per-compartment GC
| Line 87: | Line 87: | ||
'''Compartmental GC''' — Support collecting garbage in one GCSubheap without walking the rest of the graph ({{bug|558861}}) and without stopping other threads. | '''Compartmental GC''' — Support collecting garbage in one GCSubheap without walking the rest of the graph ({{bug|558861}}) and without stopping other threads. | ||
<!-- | <!-- | ||
| Line 121: | Line 123: | ||
[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). | ||
--> | |||
<!-- | |||
Someone proposed the following plan: | |||
* New API for making MT-accessible objects | |||
* Objects are ST-accessible only without new API usage | |||
* Safest course for API: #ifdef JS_AUTO_MT_OBJECTS for existing API, new API entry points (C++ API, rather) for new ST vs. MT create-object methods [bug NNNNNNN] | |||
* Switch mozilla-central code over, turn off JS_AUTO_MT_OBJECTS [bug NNNNNNN] | |||
This won't work because I plan to implement MT objects using custom JSObjectOps. So JS_AUTO_MT_OBJECTS would make all objects non-native, which would break major engine invariants (e.g. the global object must be native). | |||
--> | --> | ||