JavaScript:SpiderMonkey:GC Futures: Difference between revisions

Revision as of 18:31, 16 July 2009

Brain-dump of work items:

Speed up allocator
Speed up collector
- Allocate short-enough strings from GC heap, not malloc heap
- Allocate object dslots from GC heap, not malloc heap? Alternative:
- Based on Gregor's stats consider making 32-byte and 64-byte JSObjects to cover most cases except large objects without any dslots
Remove byte flag per thing design
- Bad cache effects of flags and things allocated from opposite ends of same arena
- Don't want generality of different thing-types allocated from same size class
  - Can put finalizer or other index/info in the pool, not in each flag's low bits
  - Compress flags to mark bit in bitmap?
Add new JNI-like (handles, "clothed" not "naked") global rooting API
- But use C++ to best effect (auto storage class RAII helpers, templates)
Make old JS global rooting API be #ifdef JS_NAKED_GC_ROOTS (enabled at first)
Convert mozilla-central to use new global rooting API
Disable JS_NAKED_GC_ROOTS
Write barrier for all code including JITted code
Write barrier in API
Make GC heap per thread (in JSThreadData)
- 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
- Switch mozilla-central code over, turn off JS_AUTO_MT_OBJECTS
Fast generational copying allocation and collection
Go to beach

@@ Line 5: / Line 5: @@
 * Speed up allocator
 * Speed up collector
-** Allocate short-enough strings and dslots from GC heap, not malloc heap
+** Allocate short-enough strings from GC heap, not malloc heap
-** Based on [https://bugzilla.mozilla.org/show_bug.cgi?id=502736|Gregor's stats] consider making 32-byte and 64-byte JSObjects to cover most cases except large objects without any dslots
+** Allocate object dslots from GC heap, not malloc heap? Alternative:
+** Based on [https://bugzilla.mozilla.org/show_bug.cgi?id=502736 Gregor's stats] consider making 32-byte and 64-byte JSObjects to cover most cases except large objects without any dslots
 * Remove byte flag per thing design
 ** Bad cache effects of flags and things allocated from opposite ends of same arena