3 ms·

> Full GC. If nothing helped, for example, when Degenerated GC had not freed up enough memory, Full GC cycle would happen, and compact the heap to the max. Cert

> Full GC. If nothing helped, for example, when Degenerated GC had not freed up enough memory, Full GC cycle would happen, and compact the heap to the max. Certain scenarios, like the unusually fragmented heap coupled with implementation performance bugs and overlooks, would be fixed only by Full GC. This last-ditch GC guarantees that application would not fail with OOM, if there is at least some memory is available. > Usual latency induced: >100 ms, but can be more, especially on a very occupied heap Seems like it confirms precisely what I wrote? You can get longer pauses the less memory you have left, i.e. the more of the heap you've used...

chrisseaton 8y ago
I mean that's effectively a deployment error. You're not supposed to run your application without enough head-room. You can degrade almost any GC by restricting the head-room. You're reading from the 'failure modes' section there.
- mehrdadn 8y ago
  > I mean that's effectively a deployment error. You're not supposed to run your application without enough head-room. You can degrade almost any GC by restricting the head-room. You're reading from the 'failure modes' section there. ...what is this nonsense? User has 5GB of RAM left and program reads 3GB. The program finishes with it and loads the next 3GB, but triggers a GC pause. He comes to you and tells you the GC paused for a long time, but instead of coming clean and admitting the pause claim was a lie, you run out of the room crying that the user "didn't run the program with enough headroom"? Why is it so hard for GC folks to admit pauses aren't unavoidable when even their GC's documentation says as much? Why is it always a user problem if the user lied to and sees reality is different?
  - chrisseaton 8y ago
    Can you tone down your comments a bit, please? There's no need to be so aggressive. It's not nonsense, I'm not lying about anything, and I'm not running about crying. > Shenandoah implicitly relies on collecting faster than application allocates That's what the documentation tells you that you need in order to deploy Shenandoah. If you can't meet that then you don't get the claimed performance characteristics. If you can meet that requirement then GC pause times are dependent on root set sizes, not heap sizes.
    - mehrdadn 8y ago
      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

I mean that's effectively a deployment error. You're not supposed to run your application without enough head-room. You can degrade almost any GC by restricting the head-room. You're reading from the 'failure modes' section there.

mehrdadn 8y ago
> I mean that's effectively a deployment error. You're not supposed to run your application without enough head-room. You can degrade almost any GC by restricting the head-room. You're reading from the 'failure modes' section there. ...what is this nonsense? User has 5GB of RAM left and program reads 3GB. The program finishes with it and loads the next 3GB, but triggers a GC pause. He comes to you and tells you the GC paused for a long time, but instead of coming clean and admitting the pause claim was a lie, you run out of the room crying that the user "didn't run the program with enough headroom"? Why is it so hard for GC folks to admit pauses aren't unavoidable when even their GC's documentation says as much? Why is it always a user problem if the user lied to and sees reality is different?
- chrisseaton 8y ago
  Can you tone down your comments a bit, please? There's no need to be so aggressive. It's not nonsense, I'm not lying about anything, and I'm not running about crying. > Shenandoah implicitly relies on collecting faster than application allocates That's what the documentation tells you that you need in order to deploy Shenandoah. If you can't meet that then you don't get the claimed performance characteristics. If you can meet that requirement then GC pause times are dependent on root set sizes, not heap sizes.
  - mehrdadn 8y ago
    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