4677861
story
Comments: 587 +- Technology: Java Gets New Garbage Collector, But Only If You Buy Support on Friday May 29 2009, @02:00PM
background: url(//a.fsdn.com/sd/topics/topicjava.gif); width:43px; height:60px;
java
background: url(//a.fsdn.com/sd/topics/topicprogramming.gif); width:80px; height:48px;
programming
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?"
Related Stories
Submission: Monetizing Java by Anonymous Coward
Java's New G1 Collector Not For-Pay After All 171 comments
Four fifths of the perjury in the world is expended on tombstones, women
and competitors.
-- Lord Thomas Dewar
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.
Seriously Java? (Score:5, Insightful)
Re:Seriously Java? (Score:5, Insightful)
So long as they publish the spec, we can't accuse them of being proprietary. So long as the free version is superior to other similar free technologies, they will still be the market leader. Sounds like they know what they're doing.
Parent
Re:Seriously Java? (Score:5, Insightful)
So long as they publish the spec, we can't accuse them of being proprietary.
Yeah, just like .NET, right?
Parent
Re:Seriously Java? (Score:5, Informative)
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).
Parent
Re:Seriously Java? (Score:5, Insightful)
You could also dispense with having to maintain two nearly-identical languages (Java and Javascript)
Huh? How are Java and Javascript nearly identical?
Parent
Re:Seriously Java? (Score:5, Funny)
They were both slow when they came out, they're both slow now, and they both have a bunch of people saying "oh, but it's faster now!"
Parent
Re:Seriously Java? (Score:5, Insightful)
Great, Ruby will fit right in.
Parent
Re:Seriously Java? (Score:5, Interesting)
I don't know about Java, but I've been playing with Google's V8 [google.com] and that sucker is fast, at least on Windows.
Parent
Re:Seriously Java? (Score:5, Informative)
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 [inria.fr]
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]
Parent
Re:Seriously Java? (Score:5, Insightful)
I don't buy it.
The first clue is that the speed of the C++ version doesn't match the C version. Of course there's a difference between "good C++" and "good C", but if your goal is speed then you're not typically concerned about those differences.
Second, reading through the scienceblog.com article, the author calls the (unavailable) code "carefully optimized," yet he claims the C code is slower than the others because of pointer aliasing. However, any modern C compiler has pragmas and compiler optimization flags that tell it to assume no aliasing occurs. How carefully could he have optimized the code if he didn't even bother turning on compiler optimizations?
I don't think the scienceblogs guy really knows enough about C and C++ to back up his claim.
Parent
Re:Seriously Java? (Score:5, Funny)
Huh? How are Java and Javascript nearly identical?
In the same way lightning is nearly identical to lightning bugs.
Parent
Re:Seriously Java? (Score:5, Funny)
Parent
Re:Seriously Java? (Score:5, Interesting)
I don't know which is true but the second possibility seems far more likely to me, making this story completely pointless and unfair - but hey this is slashdot.
Btw, off topic but is it just me or the subjects in replies are showing up as white text on white bg in Firefox but look ok in IE. I even tried in on another pc and same thing.
Parent
To View Comment Subjects (Score:5, Informative)
Parent
It's in OpenJDK too (Score:5, Informative)
Parent
Re:Seriously Java? (Score:5, Funny)
Write once. Pay everywhere.
Parent
Re:Seriously Java? (Score:5, Insightful)
Linux is better than some Unix's in some circumstances. It is not however an inarguable matter of fact. ZFS is just one possible example where an argument could be made that Solaris is better.
Parent
Garbage collector? (Score:4, Interesting)
As a non-programmer, can someone give a brief explanation of what a garbage collector is as it pertains to programming.
Re:Garbage collector? (Score:5, Informative)
Parent
Re:Garbage collector? (Score:5, Insightful)
Substitute "objects" with "memory" and "referenced" with "used", and you might actually reach the intended audience (people who aren't programmers).
Parent
Re:Garbage collector? (Score:5, Informative)
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.
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Informative)
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Insightful)
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.
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Funny)
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.
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Funny)
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.
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Insightful)
It would not be more robust.
The more things you have to pay attention to at the nuts-and-bolts level, the fewer things you are able to pay attention to at the business logic level. The key difference between managed languages like Java and non-managed languages like C, is that the uninteresting grunt work is done for you by the compiler. A vast majority of security flaws are related to programmers thinking exactly like you do. Even if the programmer is very highly skilled, memory management is tedious and difficult, and it is impossible to never make a mistake. Mistakes in memory management lead to segfaults or remote exploits.
Non-managed languages should be used only when the performance benefits outweigh the dangers.
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Informative)
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.
Parent
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:5, Insightful)
would think it would be a lot more robust to keep track of allocation and deallocation explicitly, add when you need, and delete when you don't need, and not count on some generic mechanism.
Ok... so I allocate object A. Then I allocate object B, C, and D that all reference A but aren't aware of eachother. Then I release D, and don't know whether to release A, so now A needs to have some sort of reference counting mechanism, and I have to remember to use it each time I create or copy or pass a reference to A.
Or... I can use a language that implements the reference counting stuff for me and implicitly calls it when I allocate new objects, create, copy, or pass references, and expire them as they go out of scope, without me having to write explicit destructors.
Basically, if you do any sort of remotely complicated object allocation where you are going to need to implement reference counting to keep track of them, you might as well use a garbage collector. That's what it does, it comes thoroughly debugged, and you don't have to waste time implementing and debugging your own.
So, a garbage collector language is MORE robust (assuming robust means 'more reliable').
That's not to say unmanaged code doesn't have its place, but in my experience managed code tends to get developed faster and cheaper than equivalent unmanaged code, so it only makes sense to use unmanaged code where you really need the performance or nuts&bolts control. Your typical productivity or business logic application don't. Drivers, real-time systems, etc do.
As always, use the best tool for the job. C is not always the best tool.
Parent
Re:Garbage collector? (Score:5, Informative)
When computer programs need to keep track of information, they store it in the computer's memory. The information they store is generally arranged into structures. In object-oriented languages like Java, these structures are called objects. Every object has to have its own place in memory, called an address. Two different objects cannot use the same space in memory at the same time. When a program has a new object that it needs to create, it has to know where to put it. To do this, it uses a system which allocates some memory for it. When the program is done with the object, it should be deallocated so that the same memory can later be used for a different object. If objects are not deallocated when they are done being used, then the program will grow to take up more and more memory over time until the computer runs out of memory. This is called a memory leak.
There are two main scheme for deallocating an object's memory once the program is done with it. Older programming languages use explicit memory deallocation, meaning that when the program is done with an object, it says so. This can unfortunately be somewhat problematic. If a program forgets to say that it's done with an object, then that object never gets deallocated and the program leaks memory. If the program says that it's done with an object when some other part of the program is still using the object, then a new object of a different type might be written over the old object but because the other part of the program doesn't know this has happened, all sorts of odd problems can occur.
To solve this many newer languages including Java use a technique called garbage collection. In a garbage collecting language, the program does not explicitly say when it is done with an object. Instead the garbage collection system examines the cross-references between different objects to determine whether or not it is still possible for the program to use a particular object. If using it is impossible, then the system will deallocate it. In most systems, the garbage collection doesn't run continually swooping up every new bit of space the moment it becomes available, but instead just runs periodically clearing out anything which has become unusable since the last time it ran.
Parent
Re:Garbage collector? (Score:5, Funny)
So, which pay-for-answers site do you plan to post the responses on? Or are you feeding a plagiarism detector?
Parent
Re:Garbage collector? (Score:5, Informative)
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.
Parent
Re:Garbage collector? (Score:5, Informative)
good analogy - except you forgot some important bits:
1. you have to ensure you drink all the beer, and not leave any in the can, or the servant will give it a little shake, and think "masters not finished with this one yet, I'd best leave it".
2. You are never surrounded by a clean room, there are always empty beer cans lying around waiting for the servant to collect them.
Now, as a C++ drinker, I have a mechanism that help out, every time I go to the fridge to get a beer, I pour it into the glass object and throw the can away immediately - thus never having empty cans lying around, when the glass is empty, I refill and find the empty can problem is a non-issue. (that's such a convoluted analogy for RAII!)
Parent
Reference Counting != Garbage Collection (Score:5, Informative)
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.
Parent
Re:Almost (Score:5, Informative)
Parent
In this day and age of "green" businesses... (Score:5, Funny)
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.
Re:No malloc( )s (Score:5, Funny)
Parent
Troll? (Score:5, Funny)
In Soviet Russia, article trolls you!
This was BEA's model with JRockit (Score:5, Interesting)
Perhaps (Score:5, Interesting)
"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.
It's "experimental" (Score:5, Insightful)
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."
Re:It's "experimental" (Score:5, Insightful)
I don't know...the release notes specifically say:
On the other hand, I was unable to find any specific mention of G1 anywhere in the licensing agreement. However, I did find this:
If anyone is able to point out in the actual licensing where the quote from the release notes is backed up, I'd be interested. (text near the second quote there did allow for "exceptions" and "supplemental terms" - but I wasn't able to find any pertaining to G1)
Parent
Oh you Smelly Software Socialists! (Score:5, Funny)
I just know you're going to make a lengthy complaint thread of this.
If you would simply put down your Silver Surfer comics, comb the crumbs and insects out of your beards, cut your straggly hair, have a bath and a good scrub, and eagerly learn all the new technologies as our Marketing department invents them (and disposes of the old technologies), we could see the dawn of a New Age of incredibly rich CEOs and VPs who live in mansions, collect cars, race boats and planes, and in general protect the freedoms that your betters fought so hard to establish.
The meek shall inherit my EULA.
Pull your head out of your ass (Score:5, Informative)
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...
Tony Soprano in charge (Score:5, Funny)
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?
Re:Tony Soprano in charge (Score:5, Funny)
That's a real nice production server you got here. It'd be a shame to see something unfortunate happen to it. I mean a server room's a dangerous place, ain' it? You got cables and electricity around and, well... accidents happen, if you know what I mean.
Especially with garbage lyin' around all over your memory. Pipes could get clogged, tables could fill up, processes could meet an untimely demise... you know what I'm talking about.
Now for a very reasonable fee, we can see that your garbage is collected regularly. It's a very small fee, once you think about what could happen if you didn't have folks like us around to help you. We'll see that this very nice production server continues to run in tip-top shape. Yes, our small garbage collection fee could help you avoid all sorts of unpleasantness...
Parent
It's still experimental (Score:5, Interesting)
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.
G1 is already in OpenJDK (Score:5, Informative)
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.
sensationalism (Score:5, Interesting)
The slashdot summary seems to me to have a heavy dose of sensationalism.
Oracle's implementation of java is GPL'd. What more do we want from them?
I doubt that there's been any recent research that's uncovered some fantastic new mechanism for garbage collection that was never known before. Garbage collection used to suck, and that was one of the problems, historically, with LISP. Over the decades, garbage collection has gradually gotten better. All the improvements in garbage collection are in the public domain. Gc is not generally a performance bottleneck for modern garbage-collected languages.
It would be slightly more worrisome if this new gc algorithm was patented -- but I haven't seen any evidence that it is. If it's not, then nothing is preventing anyone from making a fully GPL'd version of java with the new algorithm. If it was patented, then this would be a problem for all garbage-collected languages with open-source implemtations, not just java.
Does java's performance really depend much on the efficiency of its gc? My main complaint about java's performance is that the VM and libraries take too long to load.
G1 is for the Entreprise (Score:5, Informative)
Re:A Java hate piece on Slashdot??? (Score:5, Interesting)
Java got a bad rap back in the day when the language was poised to take over the desktop and then everyone used it, and were killed by its abysmal performance. Back in the 2000, I cursed java every week as I entered my development time into this crap-ola windows box that performed like a fat man running through a river of melted taffy. Loading an applet was a painful flow breaking experience that usually did nothing to a page. When people think of java, they think of this time. it's the slashdot two minute hate.
These days, Java works well both on the desktop and on the server. Shocking, I know. I'm currently developing a desktop app for OS X and people have no idea it's a java project. It looks and behaves as if written in Objective C. Our engineering team just wrote a server app in java that had over three million entries. At one point, it was creating nine hundred entries per second without breaking a sweat. But people don't see that. They just have mental images of all the crappy applets back in the days of yore, then make uninformed opinions about the current state of the language.
My biggest complaints about java are the inconsistent implementations between platforms so something might work great on a mac, but throws exceptions on windows. Write once, run everywhere is a lie. My code is 100% java (no native code) that runs perfect in both mac and windows, yet makes the official Linux JVM puke. I hate the fact the language is object orientated, but objects are expensive to create. I hate the fact that Swing makes it easy for good java developers to write terrible user interfaces. The GridBag layout was designed by a very bitter programmer. I hate the fact that java eats and eats all the memory it can find like a kid diving his face into birthday cake. People say there's no memory leaks in Java, but once you start playing with JOptionPane, you realize that's a nice little lie. And there is work in managing your objects. I can make an app bloat up like firefox in no time. There's a few other nitpicks, but speed has never been one of them. If it were, I would be writing my app in C++ with QT, or Objective C.
Parent