JEP 173: Remove Rarely-Used Combinations of Garbage Collectors
kirk at kodewerk.com
Thu Dec 20 04:49:13 PST 2012
IMHO Michael's points were quite strong. He didn't accidentally fall into iCMS. It was pretty much the only option that was workable. He also suggested that G1 still is too immature for his needs. I would add that my experience is that this is a common opinion among those that are bothered by long pause times. In theory iCMS shouldn't be helping but in practice. Another example of this was the tuning advice given when survivors were first introduced. You must realize that the cost models involved are so complex that it's difficult anyone to truly comment on how one configuration will cope vs another. This is why we're finding these surprising configurations out in the field.
Speaking of being out in the field, I run into clients that are suffering badly and they are already very nervous. I often (for good reason) have difficulty getting these groups to do normal things. Getting them to move to a depreciated technology... which means were taking choices off of the table. Serial vs parallel, I don't really care because I can always tune back the helper threads if need be. However, there is no replacement for iCMS and if G1 doesn't cut it....
I do believe that G1 is the future. I will be looking to move a client to the G1 in January. That said, if it doesn't work and I don't have iCMS it will be off to Azul/Zing for them. I know they do want the Oracle JVM as their first option as there are some very subtile differences between Oracle and Zing which implies a whole host of testing that they'd rather avoid. That said.... This it is my opinion that putting all of the eggs into the G1 basket isn't a wise move. We need G1 today, we will most likely need it for 8.0. Could it be depreciated by 9.0, I hope so... and then maybe by 10.0 it can finally vanish. I believe this is a less aggressive but safer path to take.
More information about the hotspot-gc-dev