4 ms·

Quite a lot of hubris in thinking they are just going to solve this as if no one has been working on it. Who knows, maybe they have, but color me skeptical.

robmccoll 11y ago
Garbage collection was solved long ago: just manage your own memory ;-)
- pekk 11y ago
  This comment shouldn't have been hit so hard. It's a valid response to people complaining about the throughput/latency tradeoff, especially in special areas like small embedded devices. Go's GC can't just remove all the latency. If you can't stand the tradeoff, then you have to manage your own memory in a way that suits your special case.
  - pkroll 11y ago
    My guess? It's not being downvoted because people don't think managing your own memory is verbotten. It's being downvoted because it's a smart-ass comment seemingly meant to be humorous more than insightful. Your reply is about 10x more useful than the parent.
eloff 11y ago
I'm sorry, what exactly is your criticism?
- spullara 11y ago
  Presenting a new GC implementation as solving the low latency problem that people have been working on for decades without any real proof.
seanmcdirmid 11y ago
Good GC is an open problem. Even though there has been much work done on the subject, there is still plenty of room for improvement! Server GC, for example, typically tends to be less concurrent to improve throughput. Client GC is more responsive, but also sacrifices throughput. Since Go is positioned for server work, it is very interesting that they are choose what is typically seen as client-side priorities.
- eloff 11y ago
  Unpredictable latency is a huge no-no in these days of responsive server applications. Long GC pauses are just not acceptable to many server developers, so I don't think it's correct to consider it only a client-side problem. If you look at the mechanical sympathy mailing list, you'll see a large group of Official Knob Turners for the Java garbage collectors discussing their trade.
  - pcwalton 11y ago
    The point is not that latency doesn't matter. It's that throughput and latency are more or less a fundamental tradeoff in GC, and latency isn't the only thing that matters.
    - eloff 11y ago
      Yes, that's true, but this GC lets you get more throughput by using more memory, so you can still decide how you want to make that trade-off. But no amount of knobs can save you from a long stop-the-world pause, so they made absolutely the right decision, in my opinion. With multi-core server CPUs, throughput is relatively cheap to obtain. Latency is hard, you can't just throw money at the problem.
- nindalf 11y ago
  Although Go was conceived as a language for the server, that's becoming less apt as time passes. Its being used in many places that the language designers hadn't initially thought of, such as iOS and Android. So the trade-offs they need to make today have to consider all possible use cases, not just the server one. Also, I think its really important that pause times be as short as possible on the server as well. If they aren't, you'd probably see an unhealthy spike in 90+ percentile responses.
mattybrennan 11y ago
They're not claiming to have a new solution. They cite a Djikstra algorithm from 1978, and explain why they believe it is a good solution for certain modern applications.
- kasey_junk 11y ago
  Sure, but they also didn't get into what would make their approach special. Are there any well used GC that aren't tricolor?

robmccoll 11y ago

Garbage collection was solved long ago: just manage your own memory ;-)

pekk 11y ago
This comment shouldn't have been hit so hard. It's a valid response to people complaining about the throughput/latency tradeoff, especially in special areas like small embedded devices. Go's GC can't just remove all the latency. If you can't stand the tradeoff, then you have to manage your own memory in a way that suits your special case.
- pkroll 11y ago
  My guess? It's not being downvoted because people don't think managing your own memory is verbotten. It's being downvoted because it's a smart-ass comment seemingly meant to be humorous more than insightful. Your reply is about 10x more useful than the parent.

eloff 11y ago

I'm sorry, what exactly is your criticism?

spullara 11y ago
Presenting a new GC implementation as solving the low latency problem that people have been working on for decades without any real proof.

seanmcdirmid 11y ago

Good GC is an open problem. Even though there has been much work done on the subject, there is still plenty of room for improvement! Server GC, for example, typically tends to be less concurrent to improve throughput. Client GC is more responsive, but also sacrifices throughput. Since Go is positioned for server work, it is very interesting that they are choose what is typically seen as client-side priorities.

eloff 11y ago
Unpredictable latency is a huge no-no in these days of responsive server applications. Long GC pauses are just not acceptable to many server developers, so I don't think it's correct to consider it only a client-side problem. If you look at the mechanical sympathy mailing list, you'll see a large group of Official Knob Turners for the Java garbage collectors discussing their trade.
- pcwalton 11y ago
  The point is not that latency doesn't matter. It's that throughput and latency are more or less a fundamental tradeoff in GC, and latency isn't the only thing that matters.
  - eloff 11y ago
    Yes, that's true, but this GC lets you get more throughput by using more memory, so you can still decide how you want to make that trade-off. But no amount of knobs can save you from a long stop-the-world pause, so they made absolutely the right decision, in my opinion. With multi-core server CPUs, throughput is relatively cheap to obtain. Latency is hard, you can't just throw money at the problem.
nindalf 11y ago
Although Go was conceived as a language for the server, that's becoming less apt as time passes. Its being used in many places that the language designers hadn't initially thought of, such as iOS and Android. So the trade-offs they need to make today have to consider all possible use cases, not just the server one. Also, I think its really important that pause times be as short as possible on the server as well. If they aren't, you'd probably see an unhealthy spike in 90+ percentile responses.

mattybrennan 11y ago

They're not claiming to have a new solution. They cite a Djikstra algorithm from 1978, and explain why they believe it is a good solution for certain modern applications.

kasey_junk 11y ago
Sure, but they also didn't get into what would make their approach special. Are there any well used GC that aren't tricolor?