4 ms·

> Pause times with Shenandoah are independent of heap size I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much

> Pause times with Shenandoah are independent of heap size I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much GC...

chrisseaton 8y ago
> I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much GC... Pause times. Not GC times. Shenandoah pauses to scan the root set only. The size of the root set doesn't grow with the size of the heap. You can have a large root set and a tiny heap, or a tiny root set and a massive heap. They're entirely independent.
- mehrdadn 8y ago
  What happens if a huge object becomes unreferenced and a new one of the same size is then allocated before the older one is GC'd (and you don't have enough memory to hold both simultaneously)? Does it just crash or does it pause to collect the older objects first?
  - deleted 8y ago
    [deleted]
  - brianpgordon 8y ago
    It won't crash, but what it does is somewhat complicated. There's a section in the OpenJDK wiki addressing this question: https://wiki.openjdk.java.net/display/shenandoah/Main#Main-FailureModes https://wiki.openjdk.java.net/display/shenandoah/Main#Main-F...
    - mehrdadn 8y ago
      > 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?
  - deleted 8y ago
    [deleted]

> Pause times with Shenandoah are independent of heap size I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much GC...

chrisseaton 8y ago

> I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much GC... Pause times. Not GC times. Shenandoah pauses to scan the root set only. The size of the root set doesn't grow with the size of the heap. You can have a large root set and a tiny heap, or a tiny root set and a massive heap. They're entirely independent.

mehrdadn 8y ago
What happens if a huge object becomes unreferenced and a new one of the same size is then allocated before the older one is GC'd (and you don't have enough memory to hold both simultaneously)? Does it just crash or does it pause to collect the older objects first?
- deleted 8y ago
  [deleted]
- brianpgordon 8y ago
  It won't crash, but what it does is somewhat complicated. There's a section in the OpenJDK wiki addressing this question: https://wiki.openjdk.java.net/display/shenandoah/Main#Main-FailureModes https://wiki.openjdk.java.net/display/shenandoah/Main#Main-F...
  - mehrdadn 8y ago
    > 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?
- deleted 8y ago
  [deleted]