3 ms·

The tradeoff here seems to be a more complicated write barrier, so the loss in performance here will for the most part not show up as time spent in the GC. I'm

The tradeoff here seems to be a more complicated write barrier, so the loss in performance here will for the most part not show up as time spent in the GC. I'm curious to see how big of an issue this will be; the only GC I've heard of with such a heavy write barrier is OCaml's, which is ameliorated by the language's disposition towards immutability.

pcwalton 10y ago
And OCaml has a generational GC, unlike Go. So Go's throughput is going to be hit even harder. Not going with a generational GC is a choice that runs against what has been accepted practice for decades. It may of course work out, but it's what I'd consider an experiment.
- fpoling 10y ago
  Typical Go code does not generate a lot of short-lived objects, compared with, say, Java or with typical usage of persistent data structures in functional languages. That removes the practical need for generational GC.
  - weberc2 10y ago
    I'm also of the impression that Go's "transactional GC" is similar to a generational GC?
    - pcwalton 10y ago
      Sort of, but it sacrifices the main benefit of generational GC by not allowing for bump allocation in the nursery.
      - fpoling 10y ago
        I thought it was compacting/moving GC, not generational one, that allowed bump-allocation.
  - pcwalton 10y ago
    If this were true, then escape analysis wouldn't be so important in Go code. But it is: the lack of it is the reason why gccgo is slow in practice.
    - fpoling 10y ago
      I see the importance of escspe analysis as another indication that tyical Go code does not generate a lot of short-lived objects on the heap. It is just the language does not allow to express particular stack-allocation idioms requiring the compiler to infer them. Compare that with Java where rather sofisticated escape analysis does not help much besides allowing to return several things cheaply from a function. Typical code there just does not follow stack-like allocation patterns.
- deleted 10y ago
  [deleted]

pcwalton 10y ago

And OCaml has a generational GC, unlike Go. So Go's throughput is going to be hit even harder. Not going with a generational GC is a choice that runs against what has been accepted practice for decades. It may of course work out, but it's what I'd consider an experiment.

fpoling 10y ago
Typical Go code does not generate a lot of short-lived objects, compared with, say, Java or with typical usage of persistent data structures in functional languages. That removes the practical need for generational GC.
- weberc2 10y ago
  I'm also of the impression that Go's "transactional GC" is similar to a generational GC?
  - pcwalton 10y ago
    Sort of, but it sacrifices the main benefit of generational GC by not allowing for bump allocation in the nursery.
    - fpoling 10y ago
      I thought it was compacting/moving GC, not generational one, that allowed bump-allocation.
- pcwalton 10y ago
  If this were true, then escape analysis wouldn't be so important in Go code. But it is: the lack of it is the reason why gccgo is slow in practice.
  - fpoling 10y ago
    I see the importance of escspe analysis as another indication that tyical Go code does not generate a lot of short-lived objects on the heap. It is just the language does not allow to express particular stack-allocation idioms requiring the compiler to infer them. Compare that with Java where rather sofisticated escape analysis does not help much besides allowing to return several things cheaply from a function. Typical code there just does not follow stack-like allocation patterns.
deleted 10y ago
[deleted]