JEP 248: Make G1 the Default Garbage Collector
kirk at kodewerk.com
Thu Apr 30 11:18:17 UTC 2015
Indeed, the improvements have been amazing. I have been getting many clients to bench with it and although the results have been mixed, overall many have been able to move forward. However I still would not recommend G1 to anyone who can’t move to 1.8.0_40. Of course this change will obviously come post _40 but still, the recent emergence of the G1 as a viable production ready collector suggests that making it a default maybe a wee bit optimistic.
The change is based on the assumption that limiting latency is often more important than maximizing throughput. If this assumption is incorrect then this change might need to be reconsidered.
I would agree with this assumption. In most cases latency is more important. However G1 doesn’t always provide lowest latency especially in smaller heaps.
G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues.
I not sure it’s prudent to treat the entire Java eco-system as guinea pigs. I believe it’s more prudent to have the willing take that first step rather than have it unwittingly dropped on everyone
At the end of the day, I don’t have any say in any of this (as it should be). All I can do is let you know what I’m seeing through my straw with the hope that you’ll find the information useful. From what I see, there is not nearly enough experience in the tuning the G1 in that is especially true in the general population to make this type of change at this point in time. I’m also not sure that we have all the tuning options we need to ensure "happy apps" in the wild. For example, I think the incremental accumulated waste in tenured regions is a problem that I’m not sure we have the tools to solve. I’m not even sure if it’s a recognized problem. In fact I’m not even sure it’s a real problem as at the moment it’s only a theory based on observations I’m making by looking at numbers of GC logs produced by applications using recent releases of the G1.
I would suggest that for Tiered the default config for 8 is was also a bit premature. I’ve had to have a number of clients have to roll back off of it.
On Apr 29, 2015, at 3:03 PM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
> Hi Kirk,
> A lot of effort is put into G1, it has been continuously improving over the last couple of years and we now believe that G1 is ready to become the default. G1 will not improve all use case, but the same is true for the other collectors. For users where throughput is the main concern, Parallel GC can still be used by specifying -XX:+UseParallelGC on the command-line.
> On 2015-04-29 09:10, Kirk Pepperdine wrote:
>> Hi all,
>> 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