Slashdot Mirror
Java's New G1 Collector Not For-Pay After All
An anonymous reader writes "As a follow-up to our previous discussion, Sun appears to have quietly edited the Java 6u14 release notes language to say now: 'G1 is available as early access in this release, please try it and give us feedback. Usage in production settings without a Java SE for Business support contract is not recommended.' So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."
Did kdawson even read the article before writing the summary? I don't see anything in the article about Java becoming more like Haskell!
Garbage collection is an amazingly boring field of computer science. It's all about tracking references and trying to keep memory from filling up while also trying to keep the overall impact on the running system down. But as boring as it may be, it's also absolutely critical in today's interpreted languages.
Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted. Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand. It will get finalized eventually, but the lack of deterministic behavior in this critical part of the object lifecycle means that there is a very big chance that unacceptable delays may occur in practice.
Give me deterministic behavior over faster GC any day.
I think this means that, if you use the new GC in a production setting and it clobbers some mission-critical piece of data, they would really like you to have some support contract with them, rather than never using G1 or Java again. It is 'early release' after all.
Sun didn't "quietly edit" the release notes; they announced it publicly and appologized for having been unclear (which seems like a bit dishonest, but not quiet).
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
This is not a change, it was clear in the previous thread that the article was completely misinterpreted. The Slashdot summary made no sense at all once it was pointed out that G1 was GPL+Classpath.
I would guess a developer said something vauge like "don't use this in production without a support contract" and it got misunderstood by the person writing the release notes. If they really wanted to forbid it I'd expect them to be competant enough to do that in the license.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
A kdawson article that totally blew something out of proportion? What a shock!
Argh, so I'm turning into the kind of person who comments without reading *either* article in question but ...
Last time this came up, plenty of people pointed out that the G1 garbage collector was available to anyone, Open Source but that it was in development and you weren't recommended to use it in production without a support contract. A number of people even pointed out the settings that anybody could change to enable the experimental G1 garbage collector on their own system.
Perhaps this is case of adjusting their wording to make it easier for Slashdot to not report incorrectly ;-)
So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."
No, it means that the original article was a misleading pile of FUD since the G1 garbage collector was released GPL + Classpath exception from the beginning. It's amusing that after being pointed out that the original submission was misleading and wrong that instead of this being a retraction that this article still tries to implicitly claim that Sun or Oracle did something wrong.
1) Java is slow
2) Java is not yet open source (or only parts of it are or isn't "really" open source)
3) Java is not available in any Linux distro's package manager
4) Java does not meet the needs of the enterprise
5) Nobody uses Java anymore
6) "Java is a heavyweight ball and chain"
7) Sun is charging people to use the new G1 garbage collector.
Java has some weaknesses and disadvantages, but the above are not among them.
This space left intentionally blank.
Well, the keys are right next to each other...
By the way, the research paper describing G1 is here.
you had me at #!
C++ doesn't have heap compaction
There are ways around this, such as the buddy heap and the Windows XP low-fragmentation heap, which round sizes up to a power of 2 and keep similarly-sized allocations together.
The reason why you are confused is because you're used to a compiled environment, where every call is an immediate action. A C/C++ program must be coded to (i.e. explicitly) deletes memory references. If you explicitly delete, you can also tie in other explicit behavior; therefore, it's common "duh this is how you do it" practice to tie "finalize" behavior to the object's deletion. But remember, it is your program's logic that has decided when to get rid of it. In a GC environment, deletion is no longer an explicit event--it is autonomous, automatic; therefore, it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference. There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference. Generally, the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away. Put differently: in Java, memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program's logic. In other words, do what you were doing before, just don't call it finalize. That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize because Java gives finalize a specific purpose that cannot act the same way.
Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
Until the deal closes Oracle has nothing to do with Sun's Day to Day operations. Once Oracle takes over take bets on what happens to MySql and Glassfish. Until then, they don't have squat to do with it.
A destructor is useless with a GC.
The finalize method was only introduced in some situation where you need to make memory cleaning easier & faster.
If you are developing a regular program, you will never need to ever think on finalize. Using WeakReferences, Handles (look NIO for instance), you don't even need to know what is finalize() and what is the subilities it has. In the same way as the .wait() or .notify() !
This is the problem with developper comming from C/C++, they have been so focussed on memory management problems that they can not understand it has been solved (with a CPU & memory cost) thru GC usage.
Having automatic memory handling, does not mean you are freed from error. One famous problem is the loitering references, a reference you did not take notice to kept a bit longer than required in your code, but unfortunatly this reference has reference to lots of objects that have also reference...etc. The problem is getting worse if the place you are keeping tis reference is under a static zone or in a daemon thread.
The known solution to this is : .intern()) unless you truly understand it and can control the memory usage impact you will have on the VM on the long run.
1- never keep a cache of objects that are external to your domain unless you know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them.
2- never store a reference to your domain in a foreign domain (worst example of this is swing client properties) unlessyou know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them
3- never use string interning (cf.
If you follow those simple advices, you will never have to think about .finalize() anymore :)
Allright, here is my question : we know that GC are now well known techniques and have reached to a suitable level of maturity. Why is there no GC directly written in the microprocessor ? I mean, these are basic feature that a processor could control and perform better than anybody else. All languages could benefit this by replacing memory allocation techniques !
This would be a huge step forward IMHO.
if the GC is working correctly, it should garbage collect the entire Java language, and flush it down the toilet.
It's still too slow
It's still not deterministic
It's still lacking IEEE-754 floating point compliance
It's still lacking STANDARD implementations of many COMMON functions
It's still NOWHERE NEAR write once, run anywhere, it's more like write once, test against 3 difference versions of the JRE, and hope users have the right CLASSPATH set.
If Oracle is about to manage Java the way they manage their database product (basically letting Microsoft get ahead with SQL Server in many respects), I think Java's in trouble with .NET rumbling straight at 'em...
...in bed
If you want to control garbage collection, you should use the real time version of Java. Go to youtube and view Java RTSJ on Wall Street pt1. Here are folks that greatly value deterministic behavior, and they are choosing Java over C++. Why? Because it is predictable and you get access to the tools, developers and tools of the Java World.
Think global, act loco
Or was Oracle/Sun tentatively testing the waters to see the community's reaction?
It'd be great if my fellow slashdotters stop giving in the PROFIT conspiration theory, just one time.
Is there anything like a hardware based GC?. Imagine all object life cycle and reference change events are fed in to GPU like dedicated hardware and the hardware determines which object can be dumped. Would it be worth?. If a GPU can process billions of whatever, why not GC. It should be there already somewhere, why it is not in wide use?.
Or was Oracle/Sun tentatively testing the waters to see the community's reaction?
It's a little early to talk about Sun as a part of Oracle. It's probable that the acquisition will clear regulatory approval, but until it does, Oracle can't play anything resembling a decision-making role in something like this.
I work at Sun, and right now our contacts with Oracle are actually more circumscribed than they'd normally be.
I think the intent was simple.
Until the code is stable, if you use the new, beta quality garbage collector in production, don't go crying to Sun for help unless you're willing to pay for a support contract.
How is that any different from most open source companies such as Red Hat?
Java is slow on PPC on Linux right now.
I guess. Or maybe it's just Netbeans. But a 1.2GHz Mac Mini running Netbeans on Mac OS X is (subjectively) about half as fast as a 1.7 GHz Sempron running Netbeans on Linux. But Netbeans on the same 1.2GHz PPC processor running Linux is dead slow.
Hmm.
I love how anytime there is a Java related post, you get these C++ fanboys griping about how bad Java is. Usually comments include things about finalize(), the GC, unsigned primitives, the Date class being a pain in the ass (really?), etc.
And then you tell people that there ARE very good ways to get around these issues, and they say, why don't you just use C++?
Are you people freaking kidding me? I mean, I am not saying that Java doesn't have it's quirks, but compared to C++??? C++ has got to be the most inconsistent, most poorly designed language I have ever encountered.
Pick up any C++ book, and 80% of the book describes what not to do just to avoid "undetermined behavior". This alone should raise red flags about the overall design of a language.
Try to get any kind of static initializion right, or predictable across different OS's. Heck, just try to add an std:string as a key to a hash_map and watch the pages of compile errors you'll get depending on your target platform. Is hash_map even a subclass of map? No. You need to resort to templating to mimic polymorphic behavior, and then try to memorize all the ridiculous rules about where you can actually put your damn template function definitions, because these too are inconsistent. How about nice things like reflection? Forget about it. Heck, I even have to manually guard against a header file being included more than once. And I love how people tell me how "powerful" C++ macros are. They aren't... people get "complicated" and "powerful" confused. A powerful macro system would allow modifications to the AST at compile time, or even perhaps at runtime. C++ macros are nothing but poorly implemented, UNpowerful, text expansions. And C++0x is a joke, a hilarious one.
They'll make it free for now... to get all of us to help them work out the bugs, then they'll start charging for it.
I mean, they are rather bland looking, have poor 3G coverage, and limited memory.
To each his own, I suppose, but Java better keep it's damn mitts off MY G1.
Mir tut es leid, Menschen daß Einfältigfehlersuchenbaumfolgendenaffen sind.