Slashdot Mirror
Java Gets New Garbage Collector, But Only If You Buy Support
An anonymous reader writes "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?"
You used to be cool.
Hold up, wait a minute, let me put some pimpin in it
Shouldn't we have "recycling collection" instead of "garbage collection"?
C'mon guys all those big 1MB and 4MB malloc()s are being shipped over to third world countries to be disassembled into bits and bytes. We should be recycling things HERE.... not throwing them away for Java to come and pick up.
Karma: Excellent. 15 moderator points expire sometime.
If you post a troll comment to an article tagged troll, do you get insightful mods?
In Soviet Russia, article trolls you!
No comprende? Let me type that a little slower for you...
Garbage collection is the process freeing objects that are no longer referenced by the program.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
"Will OpenJDK be doomed to a feature-castrated backwater while all the good stuff goes into the new Java SE for Business commercial version?""
Perhaps. But now that its GPL, maybe IBM, RH and the rest of Java's stakeholders will get onto making openjdk better than oracle's. Ill sure contribute: this is a strategic need for the foss movement.
NO SIG
Java hides the details of memory allocation from the programmer. Objects, strings, etc use memory. When they are first used, Java makes sure that the appropriate amounts of memory are allocated for the item in question. When these items are no longer in use, the garbage collector finds them and frees the memory so that it can be used for other parts of the application.
VB is another place where a garbage collector would be found. Ditto .NET.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
I don't see anything obvious preventing you from using it (no license/support keys?), it's just not recommended since it's experimental. If you're crazy enough to use it on a production server, you better have a support contract so Sun/Oracle can fix any problems that come along. That seems reasonable.
Although it'd be better if they just said "don't use it for production, period."
The G1 collector is still a "work in progress" so they are suggesting that you use it *in production* only if you have a support contract with Sun (Oracle?). This is not a big deal. You can still use it, just enable it with "-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC" on the command line...
Meet Vinny and Guido, my business associates in the waste management business.
You see, it's like this. I gotta eat. My kids gotta eat. Vinny and Guido's families have to eat.
We know where you live. It's a nice place, big houses, fancy cars. You can afford to eat, very well.
You wouldn't your neighboorhood to fall victim to all sorts of garbage dumpers, would you? How about a recycling plant, right next to where you work?
No? Well, I'm sure you'll understand when I say that it is in your best interest to respect our business model. Or else, Vinny and Guido might have to go hungry for a bit. And I assure you, they get very unfriendly when they get hungry.
Capiche?
Methinks they just want to make damn sure nobody uses this feature in a production environment. This is more of a sneak peek for paying customers who are contractually bound against using this in a production environment.
If this was included in the standard distribution, then people would use it no matter what the documentation said. And then Sun would be saddled with bug reports and whining.
There's no -1 for "I don't get it."
G1 is in the latest OpenJDK builds. Since it is GPL you are free to use it without any license restrictions.
The note in the release notes is only saying that Sun won't officially support it in their releases without a support contract.
If you are concerned, use OpenJDK.
While in theory, avoiding memory leaks is easy, in practice, it is rather difficult for anything but the most trivial programs. that's one of the reasons why garbage collection was created in the first place.
No, no, no! Creating a cycle of object references does not cause a memory leak in Java!
You are assuming that a garbage collector uses reference counting. However, reference counting doesn't work for the very reason you state, and therefore GCs don't do it that way. They actually check whether an object is usable by the program, and not just whether it has any old reference to it.
Even in modern C++, memory allocation and destruction is commonly done behind the scenes using reference counting pointers.
Whenever you are dealing with anything that resembles a complex data structure, making sure that the programmer has to think very little about memory allocation is a huge boon. Programmer productivity across the alst 50 years hasn't changed much, if we look at statements written per month. The main difference is that 50 years ago, our statements did a lot less than they do now. A programmer that doesn't have to think of memory requirements can spend more time thinking about the actual business requirements, and improving the core algorithms.
Leaving the memory management to a library is also a good way of minimizing the damage that a careless programmer can make. I remember the cost of a bad programmer in a team coding in C: It'd take longer to track his memory leaks, pointer overlaps buffer overruns than it would have taken the more reliable programmers to write the code from scratch. In languages like Java and C#, one has to really be working hard to be a true liability. There's just a lower barrier of entry. In a world that's not filled with uberprogrammers, but barely competent ones, this is a huge boon.
And that's why few shops making business software would even dare to start a new project in a language without garbage collection: Unless you have quite a special team, a great QA process and are memory constrained, you'll be more productive in a language that is further away from the metal.
Here [http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase] what sun says about it : The Garbage-First garbage collector (G1 for short) is the next-generation low-pause garbage collector that will be included in the Java HotSpot virtual machine. G1 will be the long-term replacement for the Concurrent Mark-Sweep (or CMS) garbage collector, Sun's current low-pause garbage collector. G1 targets medium to large multiprocessor machines and large heaps, relying heavily on the concurrency and parallelism such machines offer. Like CMS, G1 is generational, which benefits throughput. Unlike CMS, G1 compacts to battle fragmentation and to achieve more-consistent long-term operation. As its name suggests, G1 concentrates its collection and compaction activity first on the areas of the heap that are likely to be full of reclaimable objects, thus improving its efficiency. G1 uses a pause prediction model to meet user-defined pause time targets. It achieves smoother pause times than CMS, with fewer or no outliers at comparable or better throughput, as this presentation shows. The initial target pause times are in the low tens of milliseconds. === So this is more for entreprise multiprocessors, multiservers java. And those entreprise normally will buy a support contract. So it's almost a no news.
Protecting processes running in the same VM from each other may not seem terribly useful now, but Java was originally designed to be used in embedded controllers, where the JVM would *be* the operating system, and where processes had to be protected from each other without the help of a hardware memory management unit.
FWIW, I also beg to differ about the difficulty of manual memory management. In C++ it is usually very easy, as long as you're consistent about doing deallocations in destructors. I once had to write a 40,000+ line C++ program, with lots of dynamic memory management going on; once development was complete, I ran a complete test suite under Purify, and found 5, yes, five, memory leaks. Considering that most leaks are the result of mis-handled object ownership, which is an issue that garbage collection does not eliminate in general, you should be careful about your design, *and* use memory analyzers like OptimizeIt, even when developing in a GC environment.
Substitute "objects" with "memory" and "referenced" with "used", and you might actually reach the intended audience (people who aren't programmers).
Five memory leaks!
Ah-ah-ah.
One... two... three... four... five memory leaks!
Ah-ah-ah.
Sorry. I have a toddler at home. I couldn't help counting out loud in a silly voice when you mentioned the number 'five' twice.
br.Now my coworkers are eyeing me even more strangely than usual.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
G1 is in OpenJDK and JDK7 as well as the new JDK6. So it's open source. So fear not. I think that as people have mentioned below they are simply trying to protect themselves from people turning on this feature in a production environment and then bitching to them about it.
Holy crap! That joke cut his head off!
As a beer drinker, I drink lots of beer. When I was a C++ programmer, I had to make sure I threw away my empty beer cans after drinking the beer. Unfortunately, occasionally, I forgot to do that and pretty soon my room would fill up with empty beer cans so that I couldn't get to the fridge to get more beer out of it.
However, now I am a Java programmer and I have a servant (a beer can collector) who comes around and clears up the beer cans for me every now and again. I no longer have to worry about throwing them away myself.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
In C++, there are better ways to prevent memory leaks than carefully freeing everything in your destructors (which doesn't work anyhow if your constructor throws an an awkward moment).
You accidentally a few words. You might say you accidentally a grammar exception at an awkward moment.
Welcome to the Panopticon. Used to be a prison, now it's your home.