4 ms·

It is nonsense though. I'm frustrated to see the same lie repeated over and over again. When nobody buys the lie a new GC comes out that everyone claims this ti

It is nonsense though. I'm frustrated to see the same lie repeated over and over again. When nobody buys the lie a new GC comes out that everyone claims this time is really, truly going to do the impossible. With a giant invisible "implicit" asterisk that basically says "except when it doesn't, then it's your fault". It's been happening for... over a decade now? I don't even remember. > Shenandoah implicitly relies on collecting faster than application allocates What precisely does this even mean? How is the programmer or user supposed to provision for this? By blocking on every allocation until enough time has passed since the previous one... which merely shifts the blame for the pause from the GC onto the application? And so if there are A allocations/second and D deallocations/second and we have A < D then suddenly there's a guarantee of constant-time pauses? I don't buy that either. I'm pretty confident I could construct a counterexample if I spend some time to create a nontrivial object graph. Do you believe it?

chrisseaton 8y ago
It's not complicated - the claim is that the pause only needs to be long enough to scan and update the root set twice and perform a little book-keeping, provided that allocation is slower than collection. That's black and white. Either Shenandoah is working correctly or you need to reconfigure. How do you know if allocation is slower than collection? The logs tell you. This is the same as any performance requirement - you need to test it empirically. If you think there's an issue with the claims of Shenandoah then you should publish your work rather than just abuse.
- mehrdadn 8y ago
  I don't know what "work" of mine you're referring to (I never claimed to have a GC that can do the impossible either?), but what I'm taking issue with is the clearly bogus sentence from their summary [1], which was repeated at the top here: > Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB. You can't just write an unconditional "summary" like that with a straight face. It's practically dishonest to present it as if the giant asterisk isn't there. And this has nothing to do with the quality of the GC... I'm sure they've done great work, and if they're proud of it they probably very well should be, but that doesn't give us (or them) an excuse to advertise it as doing something it admits it doesn't do. [1] https://openjdk.java.net/jeps/189 https://openjdk.java.net/jeps/189
  - chrisseaton 8y ago
    If you know the claim is bogus then you must have done the work to prove that. Show that work to them and stop being so unpleasant to me.
    - mehrdadn 8y ago
      I thought we already established this. It was the GC documentation itself [1] that admitted the summary was bogus. Specifically: > Usual latency induced: >100 ms, but can be more, especially on a very occupied heap [1] https://wiki.openjdk.java.net/display/shenandoah/Main#Main-FailureModes https://wiki.openjdk.java.net/display/shenandoah/Main#Main-F...
      - chrisseaton 8y ago
        In a failure mode! When you have deployed it outside its system requirements!
the8472 8y ago
> 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.

chrisseaton 8y ago

It's not complicated - the claim is that the pause only needs to be long enough to scan and update the root set twice and perform a little book-keeping, provided that allocation is slower than collection. That's black and white. Either Shenandoah is working correctly or you need to reconfigure. How do you know if allocation is slower than collection? The logs tell you. This is the same as any performance requirement - you need to test it empirically. If you think there's an issue with the claims of Shenandoah then you should publish your work rather than just abuse.

mehrdadn 8y ago
I don't know what "work" of mine you're referring to (I never claimed to have a GC that can do the impossible either?), but what I'm taking issue with is the clearly bogus sentence from their summary [1], which was repeated at the top here: > Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB. You can't just write an unconditional "summary" like that with a straight face. It's practically dishonest to present it as if the giant asterisk isn't there. And this has nothing to do with the quality of the GC... I'm sure they've done great work, and if they're proud of it they probably very well should be, but that doesn't give us (or them) an excuse to advertise it as doing something it admits it doesn't do. [1] https://openjdk.java.net/jeps/189 https://openjdk.java.net/jeps/189
- chrisseaton 8y ago
  If you know the claim is bogus then you must have done the work to prove that. Show that work to them and stop being so unpleasant to me.
  - mehrdadn 8y ago
    I thought we already established this. It was the GC documentation itself [1] that admitted the summary was bogus. Specifically: > Usual latency induced: >100 ms, but can be more, especially on a very occupied heap [1] https://wiki.openjdk.java.net/display/shenandoah/Main#Main-FailureModes https://wiki.openjdk.java.net/display/shenandoah/Main#Main-F...
    - chrisseaton 8y ago
      In a failure mode! When you have deployed it outside its system requirements!

the8472 8y ago

> 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.