6 ms·

JVM's gc is most likely significantly better. On the other hand golang's gc needs to collect less objects, in some cases orders of magnitude less. If you compa

by vardump 11y ago

JVM's gc is most likely significantly better. On the other hand golang's gc needs to collect less objects, in some cases orders of magnitude less. If you compare a slice of structs with 1000 elements, it'll be one object (and allocation) in golang. Equivalent array in JVM requires the array itself + 1000 Objects, 1001 allocations. In this case, golang has lot less object graph to gc. Of course slice of 1000 interfaces or pointers faces the same 1001 issue in golang as well. You could emulate same gc load cost in JVM at cost of runtime performance by storing the objects in a byte array and [de]serialize as needed, but that's neither idiomatic or acceptable solution most of the time.

pjmlp 11y ago
Hopefully Java will get value types around version 10, but that is still quite far away. In the meantime, Azul and IBM JVMs JITs are able to optimize "value types" if the classes follow certain patterns or with some annotation help.
- aardvark179 11y ago
  Yeah, and they can collect the unreachable objects in the array when no references exist to the array itself. From the QCon talk linked to in the slides it sounds like the Go GC is benefiting from the reduced number of objects being allocated and the fact that those objects can never move. Makes things a lot simpler if you can get away with it, but I can imagine a reference into an array, and the inability to move objects could combine in bad ways if you're unlucky.
leaveyou 11y ago
Could you explain what essential things JVM does better than Go at this point ? Does it stop the world less ? Or does it do more things in parallel ? Thanks
- loganekz 11y ago
  Although Go's GC is tunable to some extent, the open source HotSpot JVM are already has multiple GC implementations that you can choose based on your use case and further tune. There is also work being done in the OpenJDK project for a GC that can collect > 100GB heaps in < 10ms [1]. There are also alternative proprietary implementations available today that already have no stop the world collections [2] [1] http://openjdk.java.net/jeps/189 http://openjdk.java.net/jeps/189 [2] https://www.azul.com/products/zing/ https://www.azul.com/products/zing/
  - leaveyou 11y ago
    From this "work being done in the OpenJDK project for a GC that can collect > 100GB heaps in < 10ms" I deduce that Go 1.6 is not that bad at all and 1.7 or 1.8 could even beat that easily. https://talks.golang.org/2016/state-of-go.slide#37 https://talks.golang.org/2016/state-of-go.slide#37 https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md https://github.com/golang/proposal/blob/master/design/12800-...
    - pcwalton 11y ago
      Latency isn't the only concern; you also have to look at throughput. The JVM's GC has been carefully tuned to strike a balance here. In particular, Go's GC is not yet generational from the talks I've seen, which is a large throughput loss compared to the GC of the JVM.
      - geodel 11y ago
        If it is carefully tuned why it needs such a big GC tuning guide and 100s of JVM flags to tune runtime. Any Java product of consequence comes with custom GC settings meaning they do not find default ones suitable. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...
        pcwalton 11y ago
        Because the JVM developers had customers who asked for the ability to tune the GC for their particular application. Go will receive those feature requests too. The Go developers may not be as willing to provide so many knobs (which is a position I'm entirely sympathetic to, don't get me wrong). But the settings always exist, regardless of whether Google hammers in values for them or leaves them adjustable. GC is full of tradeoffs; they're fundamental to the problem.
- mike_hearn 11y ago
  With respect to garbage collection only and ignoring things like reliable debugging support, the primary thing it does is compaction. If your memory manager does not compact the heap (i.e. never moves anything), then this implies a couple of things: 1. You can run out of memory whilst still technically having enough bytes available for a requested allocation, if those bytes are not contiguous. Most allocators bucket allocations by size to try and avoid the worst of this, but ultimately if you don't move things around it can always bite you. 2. The allocator has to go find a space for something when you request space. As the heap gets more and more fragmented this can slow down. If your collector is able to move objects then you can do things generationally which means allocation is effectively free (just bump a pointer). In the JVM world there are two state of the art collectors, the open source G1 and Azul's commercial C4 collector (C4 == continuous compacting concurrent collector). Both can compact the heap concurrently. It is considered an important feature for reliability because otherwise big programs can get into a state where they can't stay up forever because eventually their heap gets so fragmented that they have to restart. Note that not all programs suffer from this. It depends a lot on how a program uses memory, the types of allocations they do, their predictability, etc. But if your program does start to suffer from heap fragmentation then oh boy, is it ever painful to fix. The Go team have made a collector that does not move things. This means it can superficially look very good compared to other runtimes, but it's comparing apples to oranges: the collectors aren't doing the same amount of work. The two JVM collectors have a few other tricks up their sleeves. G1 can deduplicate strings on the heap. If you have a string like "GET" or "index.html" 1000 times in your heap, G1 can rewrite the pointers so there's only a single copy instead. C4's stand-out feature is that your app doesn't pause for GC ever, all collection is done whilst the app is running, and Azul's custom JVM is tuned to keep all other pause times absolutely minimal as well. However IIRC it needs some kernel patches in order to do this, due to the unique stresses it places on the Linux VMM subsystem.
  - colin_mccabe 11y ago
    While I agree that compaction is desirable in theory, empirically it's not really necessary. For example, there are no C/C++ malloc/free implementations that compact, because compaction would change the address of pointers, breaking the C language. Long-lived C and C++ applications seem to get by just fine without the ability to move objects in memory. Java code also tends to make more allocations than Go code, simply because Java does not (yet) have value types, and Go does. This isn't really anything to do with the GC, but it does mean that Java _needs_ a more powerful GC just to handle the sometimes much greater volume of allocations. It also makes Java programmers sometimes have to resort to hacks like arrays of primitive types (I've done this before). People like to talk about how important generational GC is, and how big a problem it is that Go doesn't have it. But I have also seen that if there is too high a volume of data in the young-gen in Java, short-lived objects get tenured anyway. In practice, the generational assumption isn't always true. If you use libraries like Protobuffers that create a ton of garbage, you can pretty easily exceed the GC's ability to keep up with short-lived garbage. I'm really curious to see how Go's GC works out for big heaps in practice. I can say that my experience with Java heaps above 100 GB has not been good. (To be fair, most of my Java experience has been under CMS, not the new G1 collector.)
voidlogic 11y ago
Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.
- kasey_junk 11y ago
  The golang object pool is a bit of a problem (compared to the JVM alternatives) due to lack of generics. You tend to need to do object pooling when you have tight performance requirements which is at odds with the type manipulation you have to do with the sync.Pool. So the golang pool is good for the case where you have GC heavy but non-latency sensitive operations, but not the more general performance sensitive problems.
  - voidlogic 11y ago
    Have you benched "myPool.Get()" vs "myPool.Get().(*myStruct)" ? I don't think the "type manipulation" is the problem you think it is.
    - pcwalton 11y ago
      At the x86 level, myPool.Get(Index) is going to be at least as expensive as cmp/jae/mov (3 cycles), and myPool.Get().(myStruct) is going to be at least as expensive as cmp/jae/cmp/jne/mov (5 cycles). So unless you have some way of hiding the latency, the type check is 67% slower by cycle count. The experience of every JIT developer is that dynamic type checks do matter a lot in hot paths.
      - voidlogic 11y ago
        This is a small fixed cost as compared to the cost of not using the pool. I wasn't suggesting the operation is free.
        kasey_junk 11y ago
        But not using a pool is not the alternative we are talking about. Rather its hand rolling your own every time. Something the JVM doesn't require.

by vardump 11y ago

pjmlp 11y ago

Hopefully Java will get value types around version 10, but that is still quite far away. In the meantime, Azul and IBM JVMs JITs are able to optimize "value types" if the classes follow certain patterns or with some annotation help.

aardvark179 11y ago
Yeah, and they can collect the unreachable objects in the array when no references exist to the array itself. From the QCon talk linked to in the slides it sounds like the Go GC is benefiting from the reduced number of objects being allocated and the fact that those objects can never move. Makes things a lot simpler if you can get away with it, but I can imagine a reference into an array, and the inability to move objects could combine in bad ways if you're unlucky.

leaveyou 11y ago

Could you explain what essential things JVM does better than Go at this point ? Does it stop the world less ? Or does it do more things in parallel ? Thanks

loganekz 11y ago
Although Go's GC is tunable to some extent, the open source HotSpot JVM are already has multiple GC implementations that you can choose based on your use case and further tune. There is also work being done in the OpenJDK project for a GC that can collect > 100GB heaps in < 10ms [1]. There are also alternative proprietary implementations available today that already have no stop the world collections [2] [1] http://openjdk.java.net/jeps/189 http://openjdk.java.net/jeps/189 [2] https://www.azul.com/products/zing/ https://www.azul.com/products/zing/
- leaveyou 11y ago
  From this "work being done in the OpenJDK project for a GC that can collect > 100GB heaps in < 10ms" I deduce that Go 1.6 is not that bad at all and 1.7 or 1.8 could even beat that easily. https://talks.golang.org/2016/state-of-go.slide#37 https://talks.golang.org/2016/state-of-go.slide#37 https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md https://github.com/golang/proposal/blob/master/design/12800-...
  - pcwalton 11y ago
    Latency isn't the only concern; you also have to look at throughput. The JVM's GC has been carefully tuned to strike a balance here. In particular, Go's GC is not yet generational from the talks I've seen, which is a large throughput loss compared to the GC of the JVM.
    - geodel 11y ago
      If it is carefully tuned why it needs such a big GC tuning guide and 100s of JVM flags to tune runtime. Any Java product of consequence comes with custom GC settings meaning they do not find default ones suitable. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...
      - pcwalton 11y ago
        Because the JVM developers had customers who asked for the ability to tune the GC for their particular application. Go will receive those feature requests too. The Go developers may not be as willing to provide so many knobs (which is a position I'm entirely sympathetic to, don't get me wrong). But the settings always exist, regardless of whether Google hammers in values for them or leaves them adjustable. GC is full of tradeoffs; they're fundamental to the problem.
mike_hearn 11y ago
With respect to garbage collection only and ignoring things like reliable debugging support, the primary thing it does is compaction. If your memory manager does not compact the heap (i.e. never moves anything), then this implies a couple of things: 1. You can run out of memory whilst still technically having enough bytes available for a requested allocation, if those bytes are not contiguous. Most allocators bucket allocations by size to try and avoid the worst of this, but ultimately if you don't move things around it can always bite you. 2. The allocator has to go find a space for something when you request space. As the heap gets more and more fragmented this can slow down. If your collector is able to move objects then you can do things generationally which means allocation is effectively free (just bump a pointer). In the JVM world there are two state of the art collectors, the open source G1 and Azul's commercial C4 collector (C4 == continuous compacting concurrent collector). Both can compact the heap concurrently. It is considered an important feature for reliability because otherwise big programs can get into a state where they can't stay up forever because eventually their heap gets so fragmented that they have to restart. Note that not all programs suffer from this. It depends a lot on how a program uses memory, the types of allocations they do, their predictability, etc. But if your program does start to suffer from heap fragmentation then oh boy, is it ever painful to fix. The Go team have made a collector that does not move things. This means it can superficially look very good compared to other runtimes, but it's comparing apples to oranges: the collectors aren't doing the same amount of work. The two JVM collectors have a few other tricks up their sleeves. G1 can deduplicate strings on the heap. If you have a string like "GET" or "index.html" 1000 times in your heap, G1 can rewrite the pointers so there's only a single copy instead. C4's stand-out feature is that your app doesn't pause for GC ever, all collection is done whilst the app is running, and Azul's custom JVM is tuned to keep all other pause times absolutely minimal as well. However IIRC it needs some kernel patches in order to do this, due to the unique stresses it places on the Linux VMM subsystem.
- colin_mccabe 11y ago
  While I agree that compaction is desirable in theory, empirically it's not really necessary. For example, there are no C/C++ malloc/free implementations that compact, because compaction would change the address of pointers, breaking the C language. Long-lived C and C++ applications seem to get by just fine without the ability to move objects in memory. Java code also tends to make more allocations than Go code, simply because Java does not (yet) have value types, and Go does. This isn't really anything to do with the GC, but it does mean that Java _needs_ a more powerful GC just to handle the sometimes much greater volume of allocations. It also makes Java programmers sometimes have to resort to hacks like arrays of primitive types (I've done this before). People like to talk about how important generational GC is, and how big a problem it is that Go doesn't have it. But I have also seen that if there is too high a volume of data in the young-gen in Java, short-lived objects get tenured anyway. In practice, the generational assumption isn't always true. If you use libraries like Protobuffers that create a ton of garbage, you can pretty easily exceed the GC's ability to keep up with short-lived garbage. I'm really curious to see how Go's GC works out for big heaps in practice. I can say that my experience with Java heaps above 100 GB has not been good. (To be fair, most of my Java experience has been under CMS, not the new G1 collector.)

voidlogic 11y ago

Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.

kasey_junk 11y ago
The golang object pool is a bit of a problem (compared to the JVM alternatives) due to lack of generics. You tend to need to do object pooling when you have tight performance requirements which is at odds with the type manipulation you have to do with the sync.Pool. So the golang pool is good for the case where you have GC heavy but non-latency sensitive operations, but not the more general performance sensitive problems.
- voidlogic 11y ago
  Have you benched "myPool.Get()" vs "myPool.Get().(*myStruct)" ? I don't think the "type manipulation" is the problem you think it is.
  - pcwalton 11y ago
    At the x86 level, myPool.Get(Index) is going to be at least as expensive as cmp/jae/mov (3 cycles), and myPool.Get().(myStruct) is going to be at least as expensive as cmp/jae/cmp/jne/mov (5 cycles). So unless you have some way of hiding the latency, the type check is 67% slower by cycle count. The experience of every JIT developer is that dynamic type checks do matter a lot in hot paths.
    - voidlogic 11y ago
      This is a small fixed cost as compared to the cost of not using the pool. I wasn't suggesting the operation is free.
      - kasey_junk 11y ago
        But not using a pool is not the alternative we are talking about. Rather its hand rolling your own every time. Something the JVM doesn't require.