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
With the JavaOne starting this week, it might be a nice opening question on day one... "What the hell are you thinking, mister Schwartz??"
As a non-programmer, can someone give a brief explanation of what a garbage collector is as it pertains to programming.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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...
JRockit has all kinds of monitoring features, memory profilers, and other useful metrics built into the JRE, but you need a license key to unlock them. Core Java was always free. You pay for the value-added stuff.
"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
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."
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
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."
* <- joke
o
-|- <- you.
/ \
did anyone really think Oracle was going to continue to release fully featured JDKs for free?????.....this is why the day Oracle bought Sun, i started learning C#....
lol, yes because C# is owned by a much more FOSS-friendly company. Microsoft would never charge to support experimental features in production-code.
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.
That works as long as the only strategy used is reference counting. There are others, and I think Java uses a fancy version of mark and sweep.
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.
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.
Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
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.
To clarify, it only works if the strategy is pure reference counting. Mark-and-sweep and reference counting with cycle detection are both special cases of the same generalised algorithm (see the IBM TJ Watson papers for more info). Generally, ref counting + cycle detection plays nicer with virtual memory and non-uniform memory architectures than mark-and-sweep, although this is less true in an aggressively generational system like G1.
I am TheRaven on Soylent News
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.
So the Oracle touch is already taking effect.
Fork you, Oracle!
[b.belong('us') for b in bases if b.owner() == 'you']
Oracle does not yet own Sun and can't (yet) set business direction for it. It's just a new, experimental feature, folks.
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.
Find free books.
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.
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.
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
Nice, now try couple of million lines of code, maintained by 50 or so developers of various levels of experience and see how many memory leaks there are then.
As the island of our knowledge grows, so does the shore of our ignorance.
What situation is that? If you're talking about tying a customer to a painful and harmful contract, then yes.
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!
Just click on the "change" button after the summary and the comment subjects display correctly. Whatever the problem is with the cached story pages, comments.pl is fine.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
If you're a sole programmer writing everything yourself, I'd be inclined to agree with you. Most work I see, however, involves significantly larger chunks than 40,000 LOC and coordination with other teams or contributors. C/C++ has no inherent unified memory management scheme, and so the patterns and responsibilities for memory management can vary widely between teams, libraries, or chunks of code. That is something that often gets overlooked when discussing Java memory management. Java GC has literally has made the coordination and use of library code very simple.
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.
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.
The entire Java Stack has long since been opened up. The community essentially owns it now. What Oracle does with "Java" I could care less.
Anything that is worth while to build design and construct/maintain Java applications and VM's is all open source.
If they want to fork and become irrelevant that is there choice.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
.
Sounds like any other typical OSS business model from Ubuntu, Novell, RedHat, IBM, and even Microsoft.
Other than cost, I'm curious as to what you are measuring.
It's not performance. Solaris 10 on a PC outperforms Linux when stressed, sometimes by huge margins. It's not a complete blow-out with modern kernels, like it was in the 2.4 days, but it's still significant -- and there are corners where it really still is a complete blow-out (like: What does fsync() do?).
It's not stability. Again, Solaris 10 is much less likely to crash or go all wonky when stressed, and AIX is similarly robust. And again there are corners here that can have large impact on reliability of applications (e.g. I recall some annoyances with direct io, although the specifics are escaping me at 3am).
It's not core features, by and large Linux lags the commercial UNIXen in that arena (e.g. Dtrace), which isn't really surprising since Linux is effectively a clone.
Having said that, there are certainly UNIXen that do not stand up so well to Linux (*cough* HP/UX *cough*), but there certainly exist UNIXen that are generally superior.
Of course, a lot depends on what you're doing with the system. If I need to push the system as hard as possible then I want Solaris if it is an option. If I am looking for general usability I find Linux preferable. The differences in the latter case are often minor (like the -c argument to "script") but taken en-masse they make for a more pleasant experience.
That's the way I see things today. I am not at all sure we won't see Linux pull into the lead over time -- it is getting better and better with age, and most UNIX systems appear to be seeing improvement stagnation. (And that may well be universal soon: What are the odds that Solaris doesn't see its R&D budget chopped under Oracle?) In summary I would generally prefer to do development on Linux, but want production on Solaris. Best of both worlds, at least today. It may be telling, though, that on my personal server systems I run Linux even when I am concerned about performance -- the ongoing administration is significantly easier it you pick the right Linux distribution, and it isn't picky about hardware like Solaris is, and the tool suite is free as in beer without any extra effort.
Except on the desktop. There MacOS is supreme IMO. All the goodness of UNIX, plus stellar UI and commercial applications. I dunno how it does in stress situations (almost nobody buys Apple servers) but it's a great desktop system.
jim frost
jimf@frostbytes.com