4 ms·

If you are interested by this topic, here is a relevant discussion on golang-nuts: https://groups.google.com/d/topic/golang-nuts/KJiyv2mV2pU/discussion https://

If you are interested by this topic, here is a relevant discussion on golang-nuts: https://groups.google.com/d/topic/golang-nuts/KJiyv2mV2pU/discussion https://groups.google.com/d/topic/golang-nuts/KJiyv2mV2pU/di... One of the arguments mentioned against having a generational GC is that it would make concurrent GC with low latency harder (because Go permits interior pointers, unlike Java) and slower (because Go only needs write barrier, unlike Java which needs read barrier as far as I know).

pcwalton 9y ago
Ian Lance Taylor is wrong in that thread. Interior pointers don't make anything harder: this is a solved problem with card marking. Indeed, .NET has interior pointers, and it doesn't cause any problem at all. Also, I don't believe that the HotSpot GC needs to use read barriers. Read barriers are only necessary if you're concurrently compacting objects (like Azul C4 does). If you have concurrent mark-and-sweep and stop the world only during compaction phases, read barriers are unnecessary.
- vitalyd 9y ago
  G1 has read barriers for SATB marking. Whether a read barrier is used or not is a function of which GC is used so can’t really say “Hotspot doesn’t use read barriers”.
  - pcwalton 9y ago
    Do you have a reference on G1 read barriers? I believe you, but I can't find any information about that from a Google search. I don't immediately see why you'd need a read barrier for snapshot-at-the-beginning. You only need to trace references from gray objects to white objects that were deleted, which is a write.
    - vitalyd 9y ago
      Sorry, that was my mistake - it has pre-write barriers for SATB but not actual read barriers. However, ZGC will have read barriers and if Shenandoah ever gets integrated into Hotspot, it has them too.
- ngrilly 9y ago
  I didn't know about .NET permitting interior pointers. Thanks. I think you're right about HotSpot GC not using read barriers. I was mixing it up with the Azul GC, which uses read barriers. > If you have concurrent mark-and-sweep and stop the world only during compaction phases, read barriers are unnecessary. Do you know if it's possible to bound the pause caused by the compaction phase to some ceiling, like 2 ms for example? I'm asking because it's a goal of Go' GC to limit GC pauses.
- ngrilly 9y ago
  > Indeed, .NET has interior pointers, and it doesn't cause any problem at all. Are you sure about this (without using C# unsafe context)? I've spent a moment digging in C# documentation and been unable to confirm this.
  - pcwalton 9y ago
    Yes. The "ref" keyword allows taking interior pointers to data members as function arguments [1]. There are also local references [2]. [1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref#passing-an-argument-by-reference https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... [2]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref#ref-locals https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
  - vitalyd 9y ago
    .NET doesn’t have interior pointer. Any `ref` must be on the stack and that’s tracked in the stackmap. You cannot have a ref as a field.
    - pcwalton 9y ago
      .NET doesn't have heap interior pointers (today), but that doesn't matter for this argument. You still need to be able to mark objects as live even if they're only referenced by interior pointers.
      - ngrilly 9y ago
        > .NET doesn't have heap interior pointers (today), but that doesn't matter for this argument. I think it matters for this argument. You are arguing that designing a garbage collector which is concurrent, low latency (pauses < 5 ms), compacting, generational, and supports interior pointers, is easy. You mentioned C#/.NET as an example, but C# doesn't have interior pointers (from heap to heap, not from stack to heap which is possible). As far as I know, neither Java, .NET, Go, Haskell, OCaml, D, V8 or Erlang satisfies all these requirements at the same time. I'm not saying it's impossible, and Ian Lance Taylor in the thread I linked earlier is not saying either. I'm just saying it's certainly hard. If it would be so easy, then most languages would already have interior pointers and a concurrent, low latency, compacting, generational GC. That's the whole difference between "today" (as in your comment) and "tomorrow".
- ngrilly 9y ago
  Here is an excerpt from the recent proposal on non-cooperative goroutine preemption [1], relevant to our discussion on GC and interior pointers: > Many other garbage-collected languages use explicit safe-points on back-edges, or they use forward-simulation to reach a safe-point. Partly, it's possible for Go to support safe-points everywhere because Go's GC already must have excellent support for interior pointers; in many languages, interior pointers never appear at a safe-point. > [...] > Decoupling stack-move points from GC safe-points. [...] Such optimizations are possible because of Go's non-moving collector. [1] https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md https://github.com/golang/proposal/blob/master/design/24543-...

pcwalton 9y ago

Ian Lance Taylor is wrong in that thread. Interior pointers don't make anything harder: this is a solved problem with card marking. Indeed, .NET has interior pointers, and it doesn't cause any problem at all. Also, I don't believe that the HotSpot GC needs to use read barriers. Read barriers are only necessary if you're concurrently compacting objects (like Azul C4 does). If you have concurrent mark-and-sweep and stop the world only during compaction phases, read barriers are unnecessary.

vitalyd 9y ago
G1 has read barriers for SATB marking. Whether a read barrier is used or not is a function of which GC is used so can’t really say “Hotspot doesn’t use read barriers”.
- pcwalton 9y ago
  Do you have a reference on G1 read barriers? I believe you, but I can't find any information about that from a Google search. I don't immediately see why you'd need a read barrier for snapshot-at-the-beginning. You only need to trace references from gray objects to white objects that were deleted, which is a write.
  - vitalyd 9y ago
    Sorry, that was my mistake - it has pre-write barriers for SATB but not actual read barriers. However, ZGC will have read barriers and if Shenandoah ever gets integrated into Hotspot, it has them too.
ngrilly 9y ago
I didn't know about .NET permitting interior pointers. Thanks. I think you're right about HotSpot GC not using read barriers. I was mixing it up with the Azul GC, which uses read barriers. > If you have concurrent mark-and-sweep and stop the world only during compaction phases, read barriers are unnecessary. Do you know if it's possible to bound the pause caused by the compaction phase to some ceiling, like 2 ms for example? I'm asking because it's a goal of Go' GC to limit GC pauses.
ngrilly 9y ago
> Indeed, .NET has interior pointers, and it doesn't cause any problem at all. Are you sure about this (without using C# unsafe context)? I've spent a moment digging in C# documentation and been unable to confirm this.
- pcwalton 9y ago
  Yes. The "ref" keyword allows taking interior pointers to data members as function arguments [1]. There are also local references [2]. [1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref#passing-an-argument-by-reference https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... [2]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref#ref-locals https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- vitalyd 9y ago
  .NET doesn’t have interior pointer. Any `ref` must be on the stack and that’s tracked in the stackmap. You cannot have a ref as a field.
  - pcwalton 9y ago
    .NET doesn't have heap interior pointers (today), but that doesn't matter for this argument. You still need to be able to mark objects as live even if they're only referenced by interior pointers.
    - ngrilly 9y ago
      > .NET doesn't have heap interior pointers (today), but that doesn't matter for this argument. I think it matters for this argument. You are arguing that designing a garbage collector which is concurrent, low latency (pauses < 5 ms), compacting, generational, and supports interior pointers, is easy. You mentioned C#/.NET as an example, but C# doesn't have interior pointers (from heap to heap, not from stack to heap which is possible). As far as I know, neither Java, .NET, Go, Haskell, OCaml, D, V8 or Erlang satisfies all these requirements at the same time. I'm not saying it's impossible, and Ian Lance Taylor in the thread I linked earlier is not saying either. I'm just saying it's certainly hard. If it would be so easy, then most languages would already have interior pointers and a concurrent, low latency, compacting, generational GC. That's the whole difference between "today" (as in your comment) and "tomorrow".
ngrilly 9y ago
Here is an excerpt from the recent proposal on non-cooperative goroutine preemption [1], relevant to our discussion on GC and interior pointers: > Many other garbage-collected languages use explicit safe-points on back-edges, or they use forward-simulation to reach a safe-point. Partly, it's possible for Go to support safe-points everywhere because Go's GC already must have excellent support for interior pointers; in many languages, interior pointers never appear at a safe-point. > [...] > Decoupling stack-move points from GC safe-points. [...] Such optimizations are possible because of Go's non-moving collector. [1] https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md https://github.com/golang/proposal/blob/master/design/24543-...