4 ms·

Considering Go is showing under ~10ms GC pauses. Java's advantage seems theoretical rather than real world. I work in Java at my job and I have not seen such lo

by geodel 11y ago

Considering Go is showing under ~10ms GC pauses. Java's advantage seems theoretical rather than real world. I work in Java at my job and I have not seen such low GC pauses in Java ever. edit: Also considering huge garbage idiomatic Java libraries and user code generates, Generational GC in Java is a basic requirement not a powerful advantage over Go.

pcwalton 11y ago
Bump allocation in the nursery is a huge advantage. There's a reason why fast Go code goes out of its way to avoid allocations (notice that the benchmark tool contains an allocation profiler), and it's because allocations are expensive when you don't have a generational GC. If you do have a generational GC, then allocations are incredibly cheap: just a pointer bump and check. It's like 4 or 5 instructions compared to the dozens in a typical malloc. With that kind of collector, you don't have to spend nearly as much time tuning your program to avoid allocations. This is the reason why Java has been slow to add value types: when you have a bump allocator, they really aren't needed as much (which is not to say they aren't needed at all). In the HotSpot VM, you can tune the GC to get any type of max garbage collection pause you want (-XX:MaxGCPauseMillis). This is basic functionality that any concurrent garbage collector supports. The downside, of course, is that pauses will happen more frequently, reducing throughput. That is why just saying "it's under 10 ms, so it's really fast" is very misleading: when your GC is interruptible, you can of course get any max pause time you want. But the GC may not be able to keep up with your allocation rate, and it may start being invoked too often. That's why you need to not just look at latency, but throughput--something that sound bites won't capture.
- jlouis 11y ago
  Side note: many functional languages use the same bump alloc method because they tend to have higher allocation rates than imperative programs.
mike_hearn 11y ago
I really hope this doesn't become a meme. Pause time is only one metric that's relevant when looking at GC, another very important one is throughput. In fact you can get very low (10-50 msec) pause times with the latest JVMs even with very large heaps, you can just request it at the command line, but you'll pay for it with slower execution. There is always a tradeoff. Go doesn't have anything fundamentally new in this field. There is a report here on an adapted HotSpot (not integrated into the mainline JVM though) that gives <10msec pause times at the 99th percentile and an 8 gigabyte heap: http://welf.se/files/OL15.pdf But you pay for it with a 15% CPU overhead. Go's GC seems to actually do a full concurrent mark/sweep of the entire heap every single time. That suggests to me that throughput could be rather poor.
- pcwalton 11y ago
  > Go's GC seems to actually do a full concurrent mark/sweep of the entire heap every single time. That suggests to me that throughput could be rather poor. Not to mention that you lose bump allocation in the nursery. Nongenerational GC is a lose-lose all around.
- jlouis 11y ago
  Right, scanning large heaps means someone has to pay along the way. The Go GC pays with lowered throughput much like the adapted HotSpot VM is showing. The 10ms pause times for go were reported for a 250 gigabyte heap, however, and that is pretty amazing. But the lowered throughput has to be present as you are scanning the heap and you have enabled the write barrier to make the concurrent scanning work its invariants. In fact, the newest versions will make aggresively allocating goroutines run slower by using some of their timeslot when they request data do run the mark phase.
otterley 11y ago
Have you tried using the G1 garbage collector? http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html http://www.oracle.com/technetwork/articles/java/g1gc-1984535... See the -XX:MaxGCPauseMillis=NNN argument, you might be able to set it to 10ms on highly performant hardware.

by geodel 11y ago

pcwalton 11y ago

Bump allocation in the nursery is a huge advantage. There's a reason why fast Go code goes out of its way to avoid allocations (notice that the benchmark tool contains an allocation profiler), and it's because allocations are expensive when you don't have a generational GC. If you do have a generational GC, then allocations are incredibly cheap: just a pointer bump and check. It's like 4 or 5 instructions compared to the dozens in a typical malloc. With that kind of collector, you don't have to spend nearly as much time tuning your program to avoid allocations. This is the reason why Java has been slow to add value types: when you have a bump allocator, they really aren't needed as much (which is not to say they aren't needed at all). In the HotSpot VM, you can tune the GC to get any type of max garbage collection pause you want (-XX:MaxGCPauseMillis). This is basic functionality that any concurrent garbage collector supports. The downside, of course, is that pauses will happen more frequently, reducing throughput. That is why just saying "it's under 10 ms, so it's really fast" is very misleading: when your GC is interruptible, you can of course get any max pause time you want. But the GC may not be able to keep up with your allocation rate, and it may start being invoked too often. That's why you need to not just look at latency, but throughput--something that sound bites won't capture.

jlouis 11y ago
Side note: many functional languages use the same bump alloc method because they tend to have higher allocation rates than imperative programs.

mike_hearn 11y ago

I really hope this doesn't become a meme. Pause time is only one metric that's relevant when looking at GC, another very important one is throughput. In fact you can get very low (10-50 msec) pause times with the latest JVMs even with very large heaps, you can just request it at the command line, but you'll pay for it with slower execution. There is always a tradeoff. Go doesn't have anything fundamentally new in this field. There is a report here on an adapted HotSpot (not integrated into the mainline JVM though) that gives <10msec pause times at the 99th percentile and an 8 gigabyte heap: http://welf.se/files/OL15.pdf But you pay for it with a 15% CPU overhead. Go's GC seems to actually do a full concurrent mark/sweep of the entire heap every single time. That suggests to me that throughput could be rather poor.

pcwalton 11y ago
> Go's GC seems to actually do a full concurrent mark/sweep of the entire heap every single time. That suggests to me that throughput could be rather poor. Not to mention that you lose bump allocation in the nursery. Nongenerational GC is a lose-lose all around.
jlouis 11y ago
Right, scanning large heaps means someone has to pay along the way. The Go GC pays with lowered throughput much like the adapted HotSpot VM is showing. The 10ms pause times for go were reported for a 250 gigabyte heap, however, and that is pretty amazing. But the lowered throughput has to be present as you are scanning the heap and you have enabled the write barrier to make the concurrent scanning work its invariants. In fact, the newest versions will make aggresively allocating goroutines run slower by using some of their timeslot when they request data do run the mark phase.

otterley 11y ago

Have you tried using the G1 garbage collector? http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html http://www.oracle.com/technetwork/articles/java/g1gc-1984535... See the -XX:MaxGCPauseMillis=NNN argument, you might be able to set it to 10ms on highly performant hardware.