Getting Garbage Collection for Free
v8project.blogspot.com
v8project.blogspot.com
Also, I am a huge fan of V8. When testing my HTML5 games, V8's performance is unmatched across the board.
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.
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.
It can be very good and all, but hardly free.
> I don't believe it.
Don't believe what, exactly? That statement is true by construction. If you mean that there will be times that GC will have to run that isn't during an idle task, that seems obvious (and is covered well by the post).
The question is how much of GC can take place during those idle tasks for typical browsing, whatever web app you're writing, etc. The article states (in the "Performance evaluation" section) that for some top/typical sites benchmark that 43% of desktop GC and 31% of mobile GC happen during idle tasks. That seems like a good improvement. It's not magic GC, but it's not claiming to be.
> Normally the garbage collector fires up as soon as the Ruby interpreter thinks it needs to, which possibly results in hundreds of milliseconds of latency. With the Out-of-Band Work feature, you can run the garbage collector outside the request cycles so that garbage collection runs inside cycles are much less expensive.
The tricky part seems to be estimating how long garbage collection will take and/or the ability to stop GC if vsync is approaching.
In all seriousness: since the environment is pretty well controlled compared to native, why not exploit it?