Misleading title; garbage collection is never free. Better would be "Optimizing the garbage collector" or how about "Using a stop-the-world garbage collector without stopping the world all that much". I would have liked that. Because the article is good.<p>Also, I am a huge fan of V8. When testing my HTML5 games, V8's performance is unmatched across the board.
> <i>Garbage collection done in the idle tasks are hidden from critical, latency-sensitive operations.</i><p>I don't believe it. There must be times when the garbage collection in the idle threads needs a critical section. Which is another way of saying keeping other operations out by making them wait.<p>Just because the latency-sensitive operations aren't themselves running the GC doesn't mean they never have to suffer a delay because of it.<p>It can be very good and all, but hardly free.
Is this novel to V8? I feel like JVM etc. environments <i>must</i> have done this, but I don't know much about this field, and the article doesn't say whether there's prior work in other language environments.
I wonder how hard it would be to implement something similar on the JVM (e.g. for Clojure games) or in games/graphic apps that embed V8.<p>The tricky part seems to be estimating how long garbage collection will take and/or the ability to stop GC if vsync is approaching.
This seams like the best practical way to schedule garbage collection next to tracking the users eye movements (joke from the Go lang presentation about 1.5 GC).<p>In all seriousness: since the environment is pretty well controlled compared to native, why not exploit it?