8 ms·

Interesting article. I haven't internalized all the parameters of the Go GC, but I wonder if there's a way to tune it on the fly. For example, if I want to run

Interesting article. I haven't internalized all the parameters of the Go GC, but I wonder if there's a way to tune it on the fly. For example, if I want to run at 60 FPS (16ms/frame), and I've measured that actually doing all the CPU side work took 10ms, can I let the GC have ~5ms of GC time (rather than the <1ms advertised) at the end of my frame to increase throughput (read: less cycles burned overtime & better power efficiency)? If not in Go, can I do this elsewhere like on the JVM? Hopefully this isn't too off topic (since the article is about trade-offs of throughput vs latency).

lossolo 10y ago
I don't think you can do it with Go. But you can do it with Nim for example, there if you set 3 ms max GC time you have guarantee that you will only get 3ms of GC time. You can set max time for Java GC also, but from what I seen it's not so strict on G1 collector.
- yoklov 10y ago
  Is there a way to ensure that the amount of time you set aside for GC is, err, enough? I imagine the outcome of it being insufficient would be quite bad... eventually.
sophacles 10y ago
I don't recall a lot about it, but what you described is "real-time garbage collection". If you google that term, you should find some work/writeups related to it :)
mike_hearn 10y ago
That's a realtime GC and yes, you can buy a JVM from IBM that has one, they call it the Metronome collector: http://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 http://researcher.watson.ibm.com/researcher/view_group_subpa... Metronome has pause time in the hundreds of microseconds range. The tradeoff it makes is that, amongst other things, it requires read barriers i.e. every time you read a pointer from the heap you have to execute some extra code to interact with the GC subsystem. If you think about how often you read pointers from the heap in a typical program, well, that turns into a lot of barriers and a corresponding execution performance hit.
- mickronome 10y ago
  Per the linked article, if their claims are to be trusted, the barrier overhead is only 4%, which is amazingly low. Low enough that it's inconsequential for any application actually needing low pause times, if the claims are correct, which I unfortunately do not know. Funnny, I remember years ago reading one of the patents the GC is probably based on, and thinking the entire thing was brilliant.
- _ak 10y ago
  FWIW, Go 1.8's GC uses essentially the same techniques as Metronome.

lossolo 10y ago

I don't think you can do it with Go. But you can do it with Nim for example, there if you set 3 ms max GC time you have guarantee that you will only get 3ms of GC time. You can set max time for Java GC also, but from what I seen it's not so strict on G1 collector.

yoklov 10y ago
Is there a way to ensure that the amount of time you set aside for GC is, err, enough? I imagine the outcome of it being insufficient would be quite bad... eventually.

sophacles 10y ago

I don't recall a lot about it, but what you described is "real-time garbage collection". If you google that term, you should find some work/writeups related to it :)

mike_hearn 10y ago

That's a realtime GC and yes, you can buy a JVM from IBM that has one, they call it the Metronome collector: http://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 http://researcher.watson.ibm.com/researcher/view_group_subpa... Metronome has pause time in the hundreds of microseconds range. The tradeoff it makes is that, amongst other things, it requires read barriers i.e. every time you read a pointer from the heap you have to execute some extra code to interact with the GC subsystem. If you think about how often you read pointers from the heap in a typical program, well, that turns into a lot of barriers and a corresponding execution performance hit.

mickronome 10y ago
Per the linked article, if their claims are to be trusted, the barrier overhead is only 4%, which is amazingly low. Low enough that it's inconsequential for any application actually needing low pause times, if the claims are correct, which I unfortunately do not know. Funnny, I remember years ago reading one of the patents the GC is probably based on, and thinking the entire thing was brilliant.
_ak 10y ago
FWIW, Go 1.8's GC uses essentially the same techniques as Metronome.