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?"
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.
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.
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...
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.
Java and Javascript are only nearly identical in that they both contain Java in their names.
Javascript is much closer to Ruby than it is Java (but the built in objects aren't generally as rich, and people scream and whine about the prototype based object system).
Nerd rage is the funniest rage.
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.
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
You're a funny guy but obviously have zero idea about what you are talking about. It's a bit aggravating that ignorant folk still come out with the same old 'slow' mantra and unfortunately even more ignorant folk buy into it. That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).
I used to eschew Java for the speed of C++ but now I've completely switched to Java for most development tasks (apart from some C glue-code [JNI] when I need to integrate some scientific instrument or another). I'm doing instrument control, image processing and analysis and I need both reasonable latency, multithreading support, and every performance cycle I can get, and yet Java is plenty fast enough for me (and even embedded devices these days have relatively large amounts of RAM this is far less of an issue than it used to be).
Seriously Java is very fast these days. Graphics2D is all done in Direct3D or OpenGL shaders, the VM is very optimised and quite often approaches FORTRAN (which is faster than C). Don't believe me? check out the links below.
So please, next time stop with the FUD (that used to be marginally true 5 years ago) and start with an open mind.
"However, High Performance Computing applications written in Java have recently won benchmark competitions. In 2008, Apache Hadoop, an open source High Performance Computing project written in Java was able to sort a terabyte of integers the fastest.[46]"
http://hal.inria.fr/inria-00312039/en
Current State of Java for HPC
At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3]