4 ms·

> which merely shifts the blame for the pause from the GC onto the application? There is no shift here, this has always been how things work. GCs are not a mag

> which merely shifts the blame for the pause from the GC onto the application? There is no shift here, this has always been how things work. GCs are not a magic wand that allow you to do anything with reckless disregard towards efficiency with zero drawbacks (neither do malloc/free). Improved GC algorithms strive to cover more and more real-world workloads. Sometimes they fall short. Sometimes the developer did inefficient things that could benefit from optimizations to decrease allocation rates. A classic example is the O(n²) string appending (+=) behavior for which one should use StringBuilders instead. It just puts unnecessary stress on the GC. G1GC had issues with LRU-like in-memory cache workloads. Some of those were improved with ongoing G1 development, but ultimately the new concurrent collectors (ZGC, shenandoah) solve those problems better since their pause times do not explode when many inter-region pointers need to be updated.

mehrdadn 8y ago
Well that's exactly the point too. GC's aren't magic wands, and people just need to be honest about the inherent limitations of whatever they build or use. You can't claim X is independent of Y when it very clearly cannot be, no matter how much you want that to be the case. That's all I'm saying.
- the8472 8y ago
  The length of individual pauses is independent of your heap size. It still depends on your root set size (which includes thread stacks). Other factors (CPU cycles consumed, throughput) depend on your heap size and allocation rates. Those performance goals are only valid when given enough spare resources (heap > live set size, cpu cores). If there are insufficient resources then the VM may eventually enter those "failure modes" to keep the application running, albeit at reduced performance, instead of crashing. I think there are flags to make it just exit if that's preferable over latency spikes. Ultimately you cannot ask it to do the impossible, this much should be obvious.

mehrdadn 8y ago

Well that's exactly the point too. GC's aren't magic wands, and people just need to be honest about the inherent limitations of whatever they build or use. You can't claim X is independent of Y when it very clearly cannot be, no matter how much you want that to be the case. That's all I'm saying.

the8472 8y ago
The length of individual pauses is independent of your heap size. It still depends on your root set size (which includes thread stacks). Other factors (CPU cycles consumed, throughput) depend on your heap size and allocation rates. Those performance goals are only valid when given enough spare resources (heap > live set size, cpu cores). If there are insufficient resources then the VM may eventually enter those "failure modes" to keep the application running, albeit at reduced performance, instead of crashing. I think there are flags to make it just exit if that's preferable over latency spikes. Ultimately you cannot ask it to do the impossible, this much should be obvious.