5 ms·

> Tangent: Go GC (generational, non-copying, concurrent mark and concurrent sweep) I think that Go GC is not generational. If I'm not mistaken, the keynote you

> Tangent: Go GC (generational, non-copying, concurrent mark and concurrent sweep) I think that Go GC is not generational. If I'm not mistaken, the keynote you linked explains they tried it and the gain were not there.

johncolanduoni 7y ago
They tried it without going as far as bump-pointer allocation in the nursery, so I wouldn’t say that Go’s GC journey away from generational was due to measuring it and it not working. I don’t think anyone has high expectations for the performance of non-copying generational GC. IIRC the presentation just said they weren’t willing to try copying because they didn’t think it would be possible to maintain good latency. Which I think Azul and perhaps a future evolution of the new JVM collectors would have something the say about.
- geodel 7y ago
  > Which I think Azul and perhaps a future evolution of the new JVM collectors would have something the say about. That something is much higher memory requirement for same size workload as compared to Go.
munificent 7y ago
This makes sense for Go. A big part of the reason the generational hypothesis is true for most applications is that they allocate short-lived objects inside function bodies that are no longer needed when the function returns. In Go, most of those objects actually do get allocated directly on the stack, or as fields directly inside other objects. So they are never seen by the GC. This is one of the aspects of the language design that I really admire. Or, you could look at as saying that Go does have a generational memory manager, and the first generation is "on the stack".
- apta 7y ago
  > In Go, most of those objects actually do get allocated directly on the stack, or as fields directly inside other objects. Most golang code I've seen still relies on pointers to objects, so unless escape analysis is better than say what the JVM or .NET offer, it's not really that different from them. .NET already has value types, and the JVM should be getting them soonish. So there really isn't that much difference from this aspect.
  - CamouflagedKiwi 7y ago
    There is a vast difference in this aspect; a []SomeStruct makes two allocations (one for the control structures, one for the data), which might be on the stack or not. Conversely an ArrayList<SomeClass> makes a linear number of allocations; each object in it is separately allocated. As you say, value types are coming soon, but they don't exist now, so right now there is a lot of difference (and in practice will be for a long time, because not everything is going to migrate to value types immediately).
    - geodel 7y ago
      And even after value types arrive it will be years before library ecosystem leverage that. Typical Java projects use dozens of 3rd party libraries and they are not going to see much effect in next 5 years.
      - miskin 7y ago
        But most of the value of value types would be in your own code to remove boilerplate code. From outside it will for sure be just another class so libraries and frameworks do not need to know abuot your value types.
- barrkel 7y ago
  The generational hypothesis works best when most memory allocations over time are rooted by call stacks that sooner or later return to a core loop. Start rooting things in long-lived stack frames, or in static things like a cache, and things get worse. Whether the language uses value types or heap allocated types changes the constant factor, but the core hypothesis isn't affected - you can't allocate everything on the stack. Memory copying costs start overtaking GC overhead if you try too hard.
kardianos 7y ago
Go's GC is not currently generational. As others have mentioned, Go gives you more control over memory which helps considerably. If you want to know more about the current progress, there is a great presentation -> blog here: https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote And you can see the most recent generational GC code here: https://go-review.googlesource.com/c/go/+/137482 https://go-review.googlesource.com/c/go/+/137482 Though my guess is it won't get merged into mainline for Go1.13 as it is already in code freeze.

johncolanduoni 7y ago

They tried it without going as far as bump-pointer allocation in the nursery, so I wouldn’t say that Go’s GC journey away from generational was due to measuring it and it not working. I don’t think anyone has high expectations for the performance of non-copying generational GC. IIRC the presentation just said they weren’t willing to try copying because they didn’t think it would be possible to maintain good latency. Which I think Azul and perhaps a future evolution of the new JVM collectors would have something the say about.

geodel 7y ago
> Which I think Azul and perhaps a future evolution of the new JVM collectors would have something the say about. That something is much higher memory requirement for same size workload as compared to Go.

munificent 7y ago

This makes sense for Go. A big part of the reason the generational hypothesis is true for most applications is that they allocate short-lived objects inside function bodies that are no longer needed when the function returns. In Go, most of those objects actually do get allocated directly on the stack, or as fields directly inside other objects. So they are never seen by the GC. This is one of the aspects of the language design that I really admire. Or, you could look at as saying that Go does have a generational memory manager, and the first generation is "on the stack".

apta 7y ago
> In Go, most of those objects actually do get allocated directly on the stack, or as fields directly inside other objects. Most golang code I've seen still relies on pointers to objects, so unless escape analysis is better than say what the JVM or .NET offer, it's not really that different from them. .NET already has value types, and the JVM should be getting them soonish. So there really isn't that much difference from this aspect.
- CamouflagedKiwi 7y ago
  There is a vast difference in this aspect; a []SomeStruct makes two allocations (one for the control structures, one for the data), which might be on the stack or not. Conversely an ArrayList<SomeClass> makes a linear number of allocations; each object in it is separately allocated. As you say, value types are coming soon, but they don't exist now, so right now there is a lot of difference (and in practice will be for a long time, because not everything is going to migrate to value types immediately).
  - geodel 7y ago
    And even after value types arrive it will be years before library ecosystem leverage that. Typical Java projects use dozens of 3rd party libraries and they are not going to see much effect in next 5 years.
    - miskin 7y ago
      But most of the value of value types would be in your own code to remove boilerplate code. From outside it will for sure be just another class so libraries and frameworks do not need to know abuot your value types.
barrkel 7y ago
The generational hypothesis works best when most memory allocations over time are rooted by call stacks that sooner or later return to a core loop. Start rooting things in long-lived stack frames, or in static things like a cache, and things get worse. Whether the language uses value types or heap allocated types changes the constant factor, but the core hypothesis isn't affected - you can't allocate everything on the stack. Memory copying costs start overtaking GC overhead if you try too hard.

kardianos 7y ago

Go's GC is not currently generational. As others have mentioned, Go gives you more control over memory which helps considerably. If you want to know more about the current progress, there is a great presentation -> blog here: https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote And you can see the most recent generational GC code here: https://go-review.googlesource.com/c/go/+/137482 https://go-review.googlesource.com/c/go/+/137482 Though my guess is it won't get merged into mainline for Go1.13 as it is already in code freeze.