JVMs can try to dynamically adjust their GC heuristics by trying to match pause time goals. The thing they'd be missing is a "global" scheduler that can inform it of upcoming work and its latency sensitivity.
Is this novel to V8? I feel like JVM etc. environments must 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.
> 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.
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.
Also, I am a huge fan of V8. When testing my HTML5 games, V8's performance is unmatched across the board.
> Garbage collection done in the idle tasks are hidden from critical, latency-sensitive operations.
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.
>> Garbage collection done in the idle tasks are hidden from critical, latency-sensitive operations.
> 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.
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).
In all seriousness: since the environment is pretty well controlled compared to native, why not exploit it?
11 comments
[ 3.0 ms ] story [ 31.2 ms ] threadThe tricky part seems to be estimating how long garbage collection will take and/or the ability to stop GC if vsync is approaching.
http://www.azulsystems.com/technology/java-garbage-collectio...
> 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.
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.
In all seriousness: since the environment is pretty well controlled compared to native, why not exploit it?