JEP 248: Make G1 the Default Garbage Collector
kirk at kodewerk.com
Wed Apr 29 07:10:53 UTC 2015
Is the G1 ready for this? I see many people moving to G1 but also I’m not sure that we’ve got the tunable correct. I’ve been sorting through a number of recent tuning engagements and my conclusion is that I would like the collector to be aggressive about collecting tenured regions at the beginning of a JVM’s life time but then become less aggressive over time. The reason is the residual waste that I see left behind because certain regions never hit the threshold needed to be included in the CSET. But, on aggregate, the number of regions in this state does start to retain a significant about of dead data. The only way to see the effects is to run regular Full GCs.. which of course you don’t really want to do. However, the problem seems to settle down a wee bit over time which is why I was thinking that being aggressive about what is collected in the early stages of a JVMs life should lead to better packing and hence less waste.
Note, I don’t really care about the memory waste, only it’s effect on cycle frequencies and pause times.
Sorry but I don’t have anything formal about this as I (and I believe many others) are still sorting out what to make of the G1 in prod. Generally the overall results are good but sometimes it’s not that way up front and how to improve things is sometimes challenging.
On a side note, the move to Tiered in 8 has also caused a bit of grief. Metaspace has caused a bit of grief and even parallelStream, which works, has come with some interesting side effect. Everyone has been so enamored with Lambdas (rightfully so) that the other stuff has been completely forgotten and some of it has surprised people. I guess I’ll be submitting a talk for J1 on some of the field experience I’ve had with the other stuff.
On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/248
> - Mark
More information about the hotspot-dev