36 ms·
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 cl
by 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 agoIf 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 agoI 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 agoIn a failure mode! When you have deployed it outside its system requirements!