JavaScript:SpiderMonkey:GC Futures: Difference between revisions

Jump to navigation Jump to search

JavaScript:SpiderMonkey:GC Futures (view source)

Revision as of 01:04, 24 April 2010

2,028 bytes removed ,  24 April 2010
→‎JS GC Futures
(crash compartments into here)
Line 6: Line 6:


* Speed up allocator
* Speed up allocator
** remove or mitigate locking ????
** Remove reserved objects and doubles stuff in the tracer [https://bugzilla.mozilla.org/show_bug.cgi?id=508140 bug 508140]
** Remove js_AddAsGCBytes [https://bugzilla.mozilla.org/show_bug.cgi?id=505933 bug 505933] FIXED
** Use one single GC heap chunk, avoiding frequent mmap and malloc calls [https://bugzilla.mozilla.org/show_bug.cgi?id=508707 bug 508707]
** Remove reserved objects and doubles stuff in the tracer [https://bugzilla.mozilla.org/show_bug.cgi?id=508140 bug 508140]  
** Use one single GC heap chunk, avoiding frequent mmap and malloc calls [https://bugzilla.mozilla.org/show_bug.cgi?id=506174 bug 508707]
* Speed up collector
* Speed up collector
** Allocate short-enough strings from GC heap, not malloc heap [https://bugzilla.mozilla.org/show_bug.cgi?id=402614 bug 402614]
** Allocate short-enough strings from GC heap, not malloc heap [https://bugzilla.mozilla.org/show_bug.cgi?id=402614 bug 402614]
** 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=508357 bug 508357]
** 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=508357 bug 508357]
** Schedule GC based on memory pressure [https://bugzilla.mozilla.org/show_bug.cgi?id=506125 bug 506125]
** Schedule GC based on memory pressure [https://bugzilla.mozilla.org/show_bug.cgi?id=506125 bug 506125]
* Remove byte flag per thing design [bug NNNNNN]
* Conservative stack scanning to avoid temp-value rooting overheads? [https://bugzilla.mozilla.org/show_bug.cgi?id=516832 bug 516832]
** 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? [https://bugzilla.mozilla.org/show_bug.cgi?id=516832 bug 516832]
*** 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
*** Resolved: we are doing this, it is safer by design, false positives are few, code is cleaner/simpler
* 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
* Go to beach


Jorend
638

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/218208"

Navigation menu