JavaScript:SpiderMonkey:GC Futures: Difference between revisions
Jump to navigation
Jump to search
| Line 7: | Line 7: | ||
* Speed up allocator | * Speed up allocator | ||
** remove or mitigate locking ???? | ** remove or mitigate locking ???? | ||
** | ** [https://bugzilla.mozilla.org/show_bug.cgi?id=506174 ] | ||
** [https://bugzilla.mozilla.org/show_bug.cgi?id=506174 Use one single GC heap chunk, avoiding frequent mmap and malloc calls] | |||
* Speed up collector | * Speed up collector | ||
** Allocate short-enough strings from GC heap, not malloc heap [bug NNNNNN] | ** Allocate short-enough strings from GC heap, not malloc heap [bug NNNNNN] | ||
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=402614 study string populations] | |||
** Allocate object dslots from GC heap, not malloc heap? Alternative: [bug NNNNNN] | ** Allocate object dslots from GC heap, not malloc heap? Alternative: [bug NNNNNN] | ||
** 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 [bug NNNNNN] | ** 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 [bug NNNNNN] | ||
Revision as of 21:01, 4 August 2009
JS GC Futures
Tracking bug is bug 505308
Brain-dump of work items:
- Speed up allocator
- remove or mitigate locking ????
- [1]
- Use one single GC heap chunk, avoiding frequent mmap and malloc calls
- Speed up collector
- Allocate short-enough strings from GC heap, not malloc heap [bug NNNNNN]
- Allocate object dslots from GC heap, not malloc heap? Alternative: [bug NNNNNN]
- Based on Gregor's stats consider making 32-byte and 64-byte JSObjects to cover most cases except large objects without any dslots [bug NNNNNN]
- Remove byte flag per thing design [bug NNNNNN]
- 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 [bug NNNNNN]
- Compress flags to mark bit in bitmap? [bug NNNNNN]
- 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) [bug NNNNNN]
- Convert mozilla-central to use new global rooting API [bug NNNNNN]
- Disable JS_NAKED_GC_ROOTS [bug NNNNNN]
- What about local roots? [bug NNNNNNN]
- Need write barrier, efficient auto-temp-value rooting [bug NNNNNNN]
- No naked argv[i] writes [bug NNNNNNN]
- Conservative stack scanning to avoid temp-value rooting overheads? [bug NNNNNNN]
- Andreas and Brendan think this is likely best (safety, clean code)
- Equivalent to well-used (i.e. seldom-used) pinning API in effect but contained:
- GC from shallow stack
- clear event loop locals that might entrain garbage
- 8/4/2009 NEEDS PROMPT INVESTIGATION
- GC safety static analysis
- Write barrier for all code including JITted code
- Write barrier in API
- write barriers may make natives slower
- 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 [bug NNNNNNN]
- Switch mozilla-central code over, turn off JS_AUTO_MT_OBJECTS [bug NNNNNNN]
- Fast generational copying allocation and collection [bug NNNNNNN]
- Go to beach