5 ms·

I haven't really read beyond the intro. I will have to read it in a fresh mind in the morning. Btw. I'm not a GC expert but I read/watched some expert commenta

by tmd83 12y ago

I haven't really read beyond the intro. I will have to read it in a fresh mind in the morning. Btw. I'm not a GC expert but I read/watched some expert commentary by some true expert. In common GC terminology (as explained already in the thread) concurrent & pauseless are not the same. I know only one GC (Azul's C4) that is pauseless. Even concurrent GCs are rare and hard to implement and GO is doing that with 1.5 There are different ways to implement concurrent GC. My knowledge is basically limited to JVM implementations and even there multiple approaches exists. Beyond the core ideas to handle concurrent GC and mutator (application) thread lies a lot of details on exactly how to lay things out in memory, whether to compact, how to pace mutator vs. GC etc. My conclusions from quite a few GC talks and the evolution of JVM GCs is that the biggest part (most man-hour involved) could very well be in fine tuning the heuristic for these details. But maybe more important for the purpose of this discussion is probably the fact that concurrent GC usually has few things balancing against each other 1. Throughput penalty (how much of the CPU is for GC, how much for application) 2. Memory overhead (how much you have to over provision your heap for GC to perform optimally) 3. How big a single pause time you will allow Generally when you make one of them better the other suffers. Some GC focuses more on one than the other and also allows to tune some of the parameter. JVM GCs I think have too many requirements and expectations on them from historic and wide spread usage. It doesn't help that in Java controlling allocation is difficult, its generally a memory hog model, the runtime is huge etc. I think the GO team is doing a nice thing by setting up the expectations early in the life of the language, the fact that its more memory/allocation friendly (if the developer wants it from what I read) and the reality of modern machine (lots of core & ram) and setting their priority. They are optimising for predictable and low pause, predictable throughout at fairly high penalty. Its hard to tune JVM GCs for 10ms pause (its doable by the experts for good code) but they are also unlikely to incur a 20% throughput penalty nor 100% heap over provision in most cases. To be fair low pause optimisation in JVM GC also incur high heap usage (often twice like GO proposal). I expect that the limit of 10ms is a soft limit though. By prioritising this heavily and the nature of GO they will probably achieve it with a lot more predictability than most other GC I presume but I don't know of any practical way to guarantee it (from my limited knowledge of course of a GC user and not implementor) except reducing mutator throughput excessively which contradicts with their other goal. But I would be very curious to see how predictable a GC GO team can make without requiring excessive tuning that JVM GC tend to require.

pjmlp 12y ago
Nice explanation. Just to add that JamaicaVM, Aonix and Websphere Real Time GCs do have hard limits on collection times according to their documentation, but I never used them so I cannot judge how they really behave.
mike_hearn 12y ago
> JVM GCs I think have too many requirements and expectations on them from historic and wide spread usage. It doesn't help that in Java controlling allocation is difficult, its generally a memory hog model, the runtime is huge etc. Well, although these things are somewhat true obviously Java didn't start out that way. It started out looking more like Go. The JVM got this way because it is so heavily used for so many things. To paraphrase jwz, the JVM is big because your needs are big. Go doesn't seem to have dramatically different goals to Java. They're both GCd languages with a standard library, memory safe code etc. The logical conclusion is that if Go became as widely used for as long as Java, it'd end up looking quite similar. The Go runtime is already walking the same path as the JVM guys did, albeit with ahead of time instead of just in time compilation. > Its hard to tune JVM GCs for 10ms pause (its doable by the experts for good code) That statement lacks too much context to mean anything. Most JVM GC pauses are young gen only and those take virtually no time at all, 10ms would be very high for such a collection. Other pauses can be just a few milliseconds as long as you don't actually run out of memory (this will force a full stop the world collection), but it tends to depend on how much free RAM you have and the sizes of the heaps, etc. State of the art collectors like Azul's and Shenandoah aim to collect heaps that are hundreds of gigabytes with pause times in the few milliseconds or less range. I don't know why Go would be more allocation friendly than Java, but I'm not a Go expert. What features are you thinking of?
- krakensden 12y ago
  Probably structs, the ease of using object pools, and the reference/value distinctions you can make.
- tmd83 12y ago
  > Well, although these things are somewhat true obviously Java didn't start out that way. It started out looking more like Go. The JVM got this way because it is so heavily used for so many things. To paraphrase jwz, the JVM is big because your needs are big. I did say that JVM is the way it is due to its wide spared use and that GO team is setting expectations of GC overhead. There are too many java programmers without any thought of GC. > That statement lacks too much context to mean anything. Most JVM GC pauses are young gen only and those take virtually no time at all, 10ms would be very high for such a collection. Other pauses can be just a few milliseconds as long as you don't actually run out of memory (this will force a full stop the world collection), but it tends to depend on how much free RAM you have and the sizes of the heaps, etc. > State of the art collectors like Azul's and Shenandoah aim to collect heaps that are hundreds of gigabytes with pause times in the few milliseconds or less range. I was expecting that anyone who knows generational GC already knows how fast most young gen GC pauses are. When you talk about pause time goals you talk about worst case times which is old gen GC. And for a big and complex heap getting to 10ms pause time is not at all easy in my limited experience. CMS and lots of memory helps but it is still no way trivial. Azul's is completely different and Shenandoah has big expectations and some nice design but only time will tell if the theories works well in practice (I do hope so). You commented on G1 in another place and while I was highly anticipating G1 in my own latency sensitive server G1 performed much worse than CMS. I didn't try to tune it much but the point remains its not as easy as just use G1, set the pause time goals and you are done. All GC (in JVM world at least) seem to start with good theories than you find it doesn't work for all kinds of realistic usage pattern and adjust. G1 had to change a lot of their assumptions once it met the real world (from the JavaOne talks of Oracle people). > I don't know why Go would be more allocation friendly than Java, but I'm not a Go expert. What features are you thinking of? I'm purely a Java guy but I think someone already gave some answer.

by tmd83 12y ago

pjmlp 12y ago

Nice explanation. Just to add that JamaicaVM, Aonix and Websphere Real Time GCs do have hard limits on collection times according to their documentation, but I never used them so I cannot judge how they really behave.

mike_hearn 12y ago

> JVM GCs I think have too many requirements and expectations on them from historic and wide spread usage. It doesn't help that in Java controlling allocation is difficult, its generally a memory hog model, the runtime is huge etc. Well, although these things are somewhat true obviously Java didn't start out that way. It started out looking more like Go. The JVM got this way because it is so heavily used for so many things. To paraphrase jwz, the JVM is big because your needs are big. Go doesn't seem to have dramatically different goals to Java. They're both GCd languages with a standard library, memory safe code etc. The logical conclusion is that if Go became as widely used for as long as Java, it'd end up looking quite similar. The Go runtime is already walking the same path as the JVM guys did, albeit with ahead of time instead of just in time compilation. > Its hard to tune JVM GCs for 10ms pause (its doable by the experts for good code) That statement lacks too much context to mean anything. Most JVM GC pauses are young gen only and those take virtually no time at all, 10ms would be very high for such a collection. Other pauses can be just a few milliseconds as long as you don't actually run out of memory (this will force a full stop the world collection), but it tends to depend on how much free RAM you have and the sizes of the heaps, etc. State of the art collectors like Azul's and Shenandoah aim to collect heaps that are hundreds of gigabytes with pause times in the few milliseconds or less range. I don't know why Go would be more allocation friendly than Java, but I'm not a Go expert. What features are you thinking of?

krakensden 12y ago
Probably structs, the ease of using object pools, and the reference/value distinctions you can make.
tmd83 12y ago
> Well, although these things are somewhat true obviously Java didn't start out that way. It started out looking more like Go. The JVM got this way because it is so heavily used for so many things. To paraphrase jwz, the JVM is big because your needs are big. I did say that JVM is the way it is due to its wide spared use and that GO team is setting expectations of GC overhead. There are too many java programmers without any thought of GC. > That statement lacks too much context to mean anything. Most JVM GC pauses are young gen only and those take virtually no time at all, 10ms would be very high for such a collection. Other pauses can be just a few milliseconds as long as you don't actually run out of memory (this will force a full stop the world collection), but it tends to depend on how much free RAM you have and the sizes of the heaps, etc. > State of the art collectors like Azul's and Shenandoah aim to collect heaps that are hundreds of gigabytes with pause times in the few milliseconds or less range. I was expecting that anyone who knows generational GC already knows how fast most young gen GC pauses are. When you talk about pause time goals you talk about worst case times which is old gen GC. And for a big and complex heap getting to 10ms pause time is not at all easy in my limited experience. CMS and lots of memory helps but it is still no way trivial. Azul's is completely different and Shenandoah has big expectations and some nice design but only time will tell if the theories works well in practice (I do hope so). You commented on G1 in another place and while I was highly anticipating G1 in my own latency sensitive server G1 performed much worse than CMS. I didn't try to tune it much but the point remains its not as easy as just use G1, set the pause time goals and you are done. All GC (in JVM world at least) seem to start with good theories than you find it doesn't work for all kinds of realistic usage pattern and adjust. G1 had to change a lot of their assumptions once it met the real world (from the JavaOne talks of Oracle people). > I don't know why Go would be more allocation friendly than Java, but I'm not a Go expert. What features are you thinking of? I'm purely a Java guy but I think someone already gave some answer.