JavaScript:SpiderMonkey:GC Futures

JS GC Futures

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
• What about local roots?
  • Need write barrier, efficient auto-temp-value rooting
  • No naked argv[i] writes
  • Conservative stack scanning to avoid temp-value rooting overheads?
• GC safety static analysis
• 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