3 ms·

The fear of GC pauses is mostly outdated. It was right in the past, but it is becoming less and less of an issue with the new GC work coming online. And for sma

by tetha 3y ago

The fear of GC pauses is mostly outdated. It was right in the past, but it is becoming less and less of an issue with the new GC work coming online. And for small heaps in web application servers, the pauses were a blip on the high percentiles of response times and you usually had a dozen other issues before that. It's similar to SWAP in Linux. It was implemented somewhat meh in older kernels, and usually if swap got hit, the system died anyhow. So there was no real difference between random processes being OOM-killed or the system grinding to a halt swapping. Modern kernels in the 4+ line have received quite a bit of work on the swap handling and swap is used a lot and very cleverly to eek out just a bit more available memory more quickly. Old habits die hard though and it takes time for old knowledge to change.

pkolaczk 3y ago
The problem of GC pauses is solved only if you can afford to waste 5x-20x more memory than the app is really using. Otherwise those low-pause modern collectors can burn a significant number of CPU cycles or even fall into emergency STW path (when they can't keep up with garbage production rate).
- xxs 3y ago
  If the allocations die trivially (the extreme/vast majority do) in the young gen, STW doesn't occur. Indeed being aware, how the GC operates is important to write a decent Java application. So is understanding how the hardware works in general.
  - pkolaczk 3y ago
    > If the allocations die trivially (the extreme/vast majority do) in the young gen Low pause GCs (ZGC, Shenadoah) for Java are not generational yet. Also, even if they were, a very high temporary object allocation rate increases young gen GC frequency and thus increases the number of objects pushed to old gen eventually. And it is not like those young gen GCs are free either. They burn quite some CPU time and they cause micro-pauses - the GC has to scan parts of the heap to learn which objects are reachable and then it has to copy the survivors. In practice, high allocation rate requires a decent amount of overhead RAM to make that process efficient. It doesn't matter if pauses are only 10 ms short if you do 50 of them per second. ;) In non-GCed languages those trivial short-term objects are typically allocated on stack and their allocation/deallocation is trivial and doesn't pause at all.
    - xxs 3y ago
      >the GC has to scan parts of the heap Hmm, for generation GCs, it should use Card marking, the pointers in the tenured gen should have means to be trivially determined where they belong to. With 64bit pointers, there is space for quite a lot of metadata, incl. the Class (or most commonly allocated/used classes).
      - pkolaczk 3y ago
        Card marking does not identify pointers directly, but only identifies parts of the heap that may contain pointers to the new gen. So those parts still need to be scanned. Surely, it is way less work than scanning the whole heap, but still non-zero.
    - the-smug-one 3y ago
      >Low pause GCs (ZGC, Shenadoah) for Java are not generational yet. They are. GenZGC is merged into mainline and got into the latest JDK, GenShenandoah didn't manage but will be in next release. >The problem of GC pauses is solved only if you can afford to waste 5x-20x more memory than the app is really using I don't think that is true. ZGC uses multi-mapping in order to dereference its colored pointers, this causes some tools to report excessive memory usage but nothing actually hits RAM.
kalleboo 3y ago
> it is becoming less and less of an issue with the new GC work coming online I feel like I've been hearing this same line for 20 years now

by tetha 3y ago

pkolaczk 3y ago

The problem of GC pauses is solved only if you can afford to waste 5x-20x more memory than the app is really using. Otherwise those low-pause modern collectors can burn a significant number of CPU cycles or even fall into emergency STW path (when they can't keep up with garbage production rate).

xxs 3y ago
If the allocations die trivially (the extreme/vast majority do) in the young gen, STW doesn't occur. Indeed being aware, how the GC operates is important to write a decent Java application. So is understanding how the hardware works in general.
- pkolaczk 3y ago
  > If the allocations die trivially (the extreme/vast majority do) in the young gen Low pause GCs (ZGC, Shenadoah) for Java are not generational yet. Also, even if they were, a very high temporary object allocation rate increases young gen GC frequency and thus increases the number of objects pushed to old gen eventually. And it is not like those young gen GCs are free either. They burn quite some CPU time and they cause micro-pauses - the GC has to scan parts of the heap to learn which objects are reachable and then it has to copy the survivors. In practice, high allocation rate requires a decent amount of overhead RAM to make that process efficient. It doesn't matter if pauses are only 10 ms short if you do 50 of them per second. ;) In non-GCed languages those trivial short-term objects are typically allocated on stack and their allocation/deallocation is trivial and doesn't pause at all.
  - xxs 3y ago
    >the GC has to scan parts of the heap Hmm, for generation GCs, it should use Card marking, the pointers in the tenured gen should have means to be trivially determined where they belong to. With 64bit pointers, there is space for quite a lot of metadata, incl. the Class (or most commonly allocated/used classes).
    - pkolaczk 3y ago
      Card marking does not identify pointers directly, but only identifies parts of the heap that may contain pointers to the new gen. So those parts still need to be scanned. Surely, it is way less work than scanning the whole heap, but still non-zero.
  - the-smug-one 3y ago
    >Low pause GCs (ZGC, Shenadoah) for Java are not generational yet. They are. GenZGC is merged into mainline and got into the latest JDK, GenShenandoah didn't manage but will be in next release. >The problem of GC pauses is solved only if you can afford to waste 5x-20x more memory than the app is really using I don't think that is true. ZGC uses multi-mapping in order to dereference its colored pointers, this causes some tools to report excessive memory usage but nothing actually hits RAM.

kalleboo 3y ago

> it is becoming less and less of an issue with the new GC work coming online I feel like I've been hearing this same line for 20 years now