JavaScript:SpiderMonkey:GC Futures: Difference between revisions
Jump to navigation
Jump to search
| Line 20: | Line 20: | ||
** Convert mozilla-central to use new global rooting API [bug NNNNNN] | ** Convert mozilla-central to use new global rooting API [bug NNNNNN] | ||
** Disable JS_NAKED_GC_ROOTS [bug NNNNNN] | ** Disable JS_NAKED_GC_ROOTS [bug NNNNNN] | ||
* What about local roots? | * What about local roots? [bug NNNNNNN] | ||
** Need write barrier, efficient auto-temp-value rooting | ** Need write barrier, efficient auto-temp-value rooting [bug NNNNNNN] | ||
** No naked argv[i] writes | ** No naked argv[i] writes [bug NNNNNNN] | ||
** Conservative stack scanning to avoid temp-value rooting overheads? | ** Conservative stack scanning to avoid temp-value rooting overheads? [bug NNNNNNN] | ||
* GC safety static analysis | * GC safety static analysis | ||
* Write barrier for all code including JITted code | * Write barrier for all code including JITted code | ||
* Write barrier in API | * Write barrier in API | ||
** write barriers may make natives slower | |||
* Make GC heap per thread (in JSThreadData) | * Make GC heap per thread (in JSThreadData) | ||
** New API for making MT-accessible objects | ** New API for making MT-accessible objects | ||
** Objects are ST-accessible only without new API usage | ** 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 | ** 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 | ** Switch mozilla-central code over, turn off JS_AUTO_MT_OBJECTS [bug NNNNNNN] | ||
* Fast generational copying allocation and collection | * Fast generational copying allocation and collection [bug NNNNNNN] | ||
* Go to beach | * Go to beach | ||
Revision as of 19:13, 20 July 2009
JS GC Futures
Brain-dump of work items:
- Speed up allocator
- remove or mitigate locking ????
- need more here????
- 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]
- 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