On 11/02/2013 02:59 PM, Brendan Eich wrote: > David Bruant wrote: >> Article version and longer talk at >> http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/ > > Thanks. > >>> They showed historical plots revealing gmail bugs, V8 GC regressions, >>> all the interesting dirt. Their tooling is great >> I wouldn't say "great". It's state-of-the-art in web development, it's >> the best things we have so far, but I still find the tool very hard to >> use and > > You're right, I should leave superlatives to their marketing. It's all > relative => standards are low :-P. Good news: we can do better in > Firefox DevTools. Thanks for your help there.
It's great to know that someone is working on this! GC tooling, leak tooling in particular, is Hard, but we should still be doing better. >>> But when they called on JS developers to manage GC pause time, they >>> lost me. >>> How are JS developers supposed to manage pause time, even indirectly >>> (by avoiding unnecessary allocations and fixing leaks)? There's no >>> way. We won't be adding manually callable gc() built-ins to the >>> standard. >> They seem to take their experience with V8 as a generality. I think >> what they meant was that allocating triggers GC which triggers copying >> (compacting?), which costs, so be careful with allocations. But this >> advice is hard to follow in practice. > > It is useless advice. > > Can we learn from pause-free or realtime GC work, e.g. Metronome by > David Bacon et al. at IBM Research? I thought Bill worked on Metronome before coming to Mozilla? In any case, his incremental GC gives us similar control over GC/mutator utilization: slices are tied to screen refresh and have controllable duration. Recently, Luke tried turning down the incremental slice time knob to see how low we could go. He found that 2ms is easily doable, except when traversing the browser C++ heap, taking about 6ms. Now that generational GC has added Heap<T> to the browser for intercepting writes, we plan to incrementalize this phase as well and target extremely low latency, low utilization GC when in "use asm". Generational GC, obviously, is harder to schedule, but collection times are generally less than 100us so we haven't bothered yet. The holy grail here is concurrent GC. Unlike Java, fully concurrent GC for JS is probably not going to be practical on 32bit platforms because of the danger of torn Values. However, in the medium term, limited concurrent nursery GC may be possible by bootstrapping off of Brian's compartment-local concurrency model and a sharded heap, ala bug 902174. Haswell's TSX instructions also provide a route forward here, albeit only on modern 64bit platforms. We'll definitely be looking harder at these once we've reduced the current backlog. > /be _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
