Is Sun offering the new G1 Garbage Collector Only with a Paid Support Contract?
Sun's Garbage First garbage collector (nicknamed G1) has been released with Java Update 1.6.0_14 (6u14). Although this low pause, server style collector has been long awaited by the developer's community, at this point Sun allows production usage only to paying customers.
G1 has been previously featured by InfoQ:
Sun's Garbage First garbage collector (hereafter referred to by its nickname G1) is the new low latency garbage collector planned to replace CMS in the Hotspot JVM. It is a server-style collector, targeted at multi-processor machines with large amounts of memory. There are two major differences between CMS and G1. The first is that G1 is a compacting collector. Compacting, a process by which live objects are moved over free memory space towards one end of the heap so that the other becomes one contiguous free area of memory, is important in long running applications because it is inevitable that the heap will fragment over time. G1 compacts sufficiently to completely avoid the use of fine-grain free lists for allocation, which considerably simplifies parts of the collector and mostly eliminates potential fragmentation issues. As well as compacting, G1 offers more predictable garbage collection pauses than can be obtained with the CMS collector and allows users to set their desired pause targets. This strong determinism gives G1 some of the characteristics of a true real-time collector but it isn't genuinely hard real-time since factors like OS scheduling still mean that the pauses cannot be guaranteed. It is however considerably easier for developers to use than the Java real-time products since existing code is able to take advantage of the improved performance that it offers without needing to make any code-level changes. G1 uses a number of interesting techniques, based on global marking information and other metrics, to prioritise regions for collection according to their GC efficiency.
G1 has been made available with update 6u14:
Garbage First, or G1, is a low pause, server style collector. G1's primary advantages over the Concurrent Mark-Sweep (CMS) collector include incremental compaction, better predictability and ease of use.
... but as the release notes explain you have to have a support contact with Sun to take it to production:
Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. G1 is supported thru Sun's Java Platform Standard Edition for Business program.
There are many that believe that this signifies a shift for Sun's policy that is connected with the acquisition from Oracle:
The monetization of Java has begun. Sun released the Java 1.6.0_14 JDK and JRE today which include a cool new garbage collector called G1. There is just one catch. Even though it is included in the distribution, the release notes state 'Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.' So the Oracle touch is already taking effect. Will OpenJDK be doomed to a feature-castrated backwater while all the good stuff goes into the new Java SE for Business commercial version?"
Others think the clause in the release notes has to do with the experimental nature of G1 and it will be removed in the future versions:
When I first read that in the release notes my first thoughts were that it followed the statement saying (paraphrased) "this code isn't production ready, but we've shipped it anyway, its not enabled by default, and your apps mightl behave differently to what you expect, if you're going to go an enable this a production environment now and you have issues, we won't help if you don't have a support contract."
I suspect when u14+ or JDK7 ships, this support requirement would likely go away.
With G1 being one of the announced features of JDK/OpenJDK 7, it seems highly unlikely at this point for Sun to keep it only for paying customers.
What do you think, should Sun monetize on some of the features of the next generation Java/JVM? What effect would that have for the platform?
Something is amiss
It's definitely not clear one way or the other. I can understand the opinion that this is merely an experimental feature and there's no indication that it will require a support contract in the future but, if so, why not mark it as such? You'd expect an experimental feature to be marked experimental.
What's more if it is experimental, wouldn't you expect Sun to suggest NOT using it in a production environment?
I'm not saying it's definitely a commercial-only feature. Nor am I saying that this will continue to be the case in JDK 7 even if it is the case with Java 6. But something is amiss and Sun/Oracle needs to clarify their position.
If I wanted to write an alternate JVM which works faster and charge money for it (JRockit?), I could. So can Sun. As long as the JDK is free and has all the features, no problem with that.
You gotta to pay for better stuff, can't have everything for free specially in corporation where they are ready to pay money for better performance.
Re: Valid Decision
So SUN is supporting experimental features provided you are under a support contract with them?
How is that experimental then? It got to work if its under a support contract.
This sounds all poorly introduced if the deal is to monetize all the apps running atop Java SE and chasing for minimal latency - just like other vendors do through JRockit Real Time and IBM J9/metronome front office edition. Why be shy about it?
Will the next move be around saying that VisualVM is for managing Java runtimes so for production and quality assurance so for customer under support fees?
The answer is "no"
Mathias Nicolajsen Kjærgaard
Russ Danner May 03, 2015