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."

Comments

Right path?

[DoofusOfDeath]

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!

But it could be!

[BadAnalogyGuy]

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.

Re:But it could be!

[yacc143]

Deterministic behaviour => use reference counting. E.g. Python has it.

But the situation with C++ is not as rosy as you paint it.

E.g. there are no guarantee that destructors on static object will be called.
Nor are destructors called on longjmp.

Re:But it could be!

[siloko]

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.

Destructor!? Finalize!? Deleted!? You talking like a crazy man, have you never heard of a system REBOOT?

Re:But it could be!

[tepples]

use reference counting != deterministic behavior

reference counting + any indirect circular reference == memory leak

hybrid GC with both reference counting and mark and sweep for cycle detection == closer to deterministic than what Java offers in the good case (no circular references) while still correct in the bad case (circular reference becoming detached from main())

Re:But it could be!

[bluefoxlucid]

Reference counters have cycle detection. See Objective-C.

Re:But it could be!

[tepples]

Nor are destructors called on longjmp.

That's one reason why setjmp was deprecated in favor of try/catch and longjmp in favor of throw.

Re:But it could be!

[Captain Spam]

use reference counting != deterministic behavior

reference counting + any indirect circular reference == memory leak

That sounds pretty deterministic to me. Indirect circular reference == memory leak, all the time. You can count on that.

Re:But it could be!

[Late Adopter]

Nor are destructors called on longjmp.

For the love of God, man, use exceptions! That's what they're for!

Re:But it could be!

[Ethanol-fueled]

What you just said makes no sense. The whole point of Java is that you don't have to mess with memory management. You've just admitted that you want to invest more time and complexity in building "mini-projects" by switching to C++. Good for learning, but otherwise practically silly if you're a noob, and you've implied that you are.

As far as Java goes, ignore the command line for now. You don't need it to quickly build decent-performing applications.

Re:But it could be!

[Late Adopter]

In the normal flow of execution your code goes out of scope and objects inside are destroyed. The purpose of EXCEPTIONS are so that when you have exceptional behavior, all aborted scopes are still properly cleaned up with object destruction. Longjmp doesn't do that. Hence my comment.

Re:But it could be!

[mpsmps]

there are no guarantee that destructors on static object will be called.

Actually, Section 3.6.3p1 of the C++ standard guarantees it. (Wonder why people who can't validate technical language claims feel qualified to mod posts that make them).

Re:But it could be!

[hibiki_r]

I write in Java every day, but if my code was running on anything other than an application server that takes care of most of my non-memory resources, I'd be wishing for the equivalent of a destructor every week.

It's not really about memory management though, but about resource management. Initialize your resources at object construction and release them at destruction is a very simple and elegant solution that is common on many C++ projects. In Java, we can't really do anything like that. We can't really encapsulate the resources without jumping through hoops.

Re:But it could be!

[ThePhilips]

'exit' is a system call ...

That was about where I stopped reading the comment.

The modern "high-level" programmers who do not understand (nor bother to try to) how their own programs actually work, fit with the system and how system is used to implement language features deserve no pity.

Go back to your Java cave.

Re:But it could be!

[shutdown -p now]

I find on Google mentions that Python which uses ref counting detects cycles.

It does, though, as I understand, the behavior is the way it is mostly for backwards-compatibility purposes.

Guido once made a list of things that he considers "implementation details" for Python, and not guarantees of the language spec - meaning that alternative Python implementations could deviate on those points from CPython. Reference counting is on that list, and e.g. Jython and IronPython do not use it at all, relying strictly on tracing GCs provided by their respective VMs.

Re:But it could be!

[shutdown -p now]

Those hoops are the same hoops you're jumping through with destructors on C++. It only looks more elegant because the complexity has all been pushed into ensuring that all objects are properly destroyed when they need to be.

It not only "looks more elegant", it is more elegant and concise, because for any given resource type, you write the cleanup code once, and then it is called automatically. With Java, you still write the code once (preferably implementing Closeable), but then you also have to call it manually all the time, resulting in a mess of nested try-finally calls:

InputStream in = new FileInputStream("foo");
try {
  OutputStream out = new FileOutputStream("bar");
  try {
...
  } finally {
    out.close();
  }
} finally {
  in.close();
}

At least C# had the decency to provide syntactic sugar for this in form of using:

using (Stream input = File.Open("foo"))
using (Stream output = File.Create("bar"))
{
...
}

But even that only deals with resources local to a method, not instance fields. And it still isn't automatic.

Even so, this feature alone would make Java so much easier to deal with. I can't believe they decided not to add it to Java 7, especially when there was a sane proposal already, and the implementation is trivial. It's probably the single most convenient feature C# has over Java (considering how often it's used).

Re:But it could be!

[shutdown -p now]

Is this a matter of your code holding references to your object, or other libraries holding references to your object?

Other libraries. You may not have a cycle between objects you control, but as soon as you expose any single one of them outside, that one can become a part of a cycle (an external object that is in a cycle holds a reference to yours), and, by extension, all objects it references. At this point, when it will die, it will die on a GC thread, when GC frees the cycle.

Then what is the right way in Java to automatically write whatever finally blocks need to be written, in the manner of Python's with statement?

Python's with statement has nothing to do with reference counting at all. It's a much simpler strategy where the programmer explicitly defines the boundary at which the resource is to be freed, irrespective of how many references there are to it. C# has a similar construct, using, which behaves much the same except for name of method that is called on block exit (__leave__ in Python, Dispose in C#), and it doesn't use reference counting at all, for any purposes.

Java actually had a bunch of proposals for a very similar thing (e.g. here is one from Google). However, none of them were accepted for Java 7 (fools...).

Re:But it could be!

[david_thornley]

Of course you don't implement finalize in Java. Since it may or may not get called, it's almost completely useless. The reason the non-deterministic behavior is not an issue is that it is assiduously avoided. What is an issue is the lack of a useful analog to finalize.

However:

In other words, instead of calling delete, you call close.

I don't call delete in C++ programs, in general. I let smart pointers take care of all of it. This means that all my resources, including memory, are automatically managed for me in a uniform manner.

This means that resource management is easier in C++ than in Java. As a C++ guy, I never have to worry about calling close or delete or anything like that. I don't have to worry about closing something too soon or too late. I don't have to worry about resource leaks, unless I do some odd things with the pointers.

You, on the other hand, have to make sure you close things. You may use the try...finally idiom, which enforces a non-cohesive chunk of code with very high coupling. In resources that get passed around and used in multiple places, you have to figure out when to call close.

In short, C++ started with a general solution for resource management, and extended it to memory management. Java picked off the easy case of memory management, and left everything else to the developer, without the tools C++ gives to manage resources.

Re:But it could be!

[david_thornley]

Smart pointers, as something you can just use, were introduced in Boost several years ago, and are in the standard now via Technical Report 1. In the mid-90s, they were possible (given template support, which was not universally good at the time), but not widespread.

Nor do I roll my own. I write the destructors, of course, and then I just use smart_ptr instead of * (okay, a bit more syntax difference than that). By now, it's not custom code.

So, in about 2000 the Java approach was generally better. Smart pointers weren't really available then for C++, and Java programmers at least didn't have to worry about memory management. Nowadays, I consider the C++ solution to be superior, since it's more general.

Well....

[samriel]

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.

Not quietly

[RPoet]

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).

Re:Not quietly

[Joehonkie]

What you said here. People were so buy foaming at the mouth that they never bothered to read the actual article or the thousands of posts that spelled out pretty clearly how and why the slashdot story got it wrong.

Re:Not quietly

[causality]

What you said here. People were so buy foaming at the mouth that they never bothered to read the actual article or the thousands of posts that spelled out pretty clearly how and why the slashdot story got it wrong.

Never seen that before. No, not ever.

It's funny when you can cut+paste your comment and drop it into multiple discussions without having to modify it. It is truly one-size-fits-all.

"Stop. Look. Listen, learn, read, think .. SHUT THE FUCK UP!" - Bill Hicks

Re:Not quietly

[BikeHelmet]

Sun didn't "quietly edit" the release notes; they announced it [sun.com] publicly and appologized for having been unclear (which seems like a bit dishonest, but not quiet).

It was established in the prior slashdot post ranting about it that it was just headline mongering. Nobody commenting had trouble understanding the true meaning.

But as usual, anything Java is SLOW, EVIL, BAD and out to steal your monies!

Slashdot editors don't read slashdot?

[argent]

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.

Probablly just a misunderstanding

[petermgreen]

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.

No Way!

[Anonymous Coward]

A kdawson article that totally blew something out of proportion? What a shock!

Re:No Way!

[harryandthehenderson]

Actually the original article was posted by ScuttleMonkey, but both are masters at spreading misleading, FUD-filled articles.

Was this ever an issue?

[Lemming Mark]

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 ;-)

Stop spreading FUD

[harryandthehenderson]

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.

Popular Java Myths

[javacowboy]

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.

Re:Popular Java Myths

[owlstead]

1) Java is slow.

I'm generally a Java advocate, but you have to take into accounts when Java *is* slow. This is mostly where Java has to get down to the nitty gritty of the bare metal. Examples are cryptography (lots and lots of low level operations on bytes, 32 and 64 bit words) and processor based instructions. In those cases it makes sense to use a well defined C library (avoiding C++ if possible) and interface with that. These are also the places where it makes sense to really optimize the hell out of an application or library.

But for general business logic this arguement is indeed long gone. I do believe that my Java applications are normally faster than their C++ counterparts for the simple reason that I've got more time to design my classes well. Even if it's slower then it's offset by the much lower maintainance cost. And it's way faster than most specialized languages. Then again, specialized languages can make sense if they are delivering lower maintainance cost. Lets just say that not choosing Java because is it slower *per se* is absolutely wrong.

Re:Popular Java Myths

[againjj]

In other words, Java is not one-size-fits-all, and all languages have tradeoffs.

Java doesn't fail

[beldraen]

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.

Re:Java doesn't fail

[deepestblue]

If you're coding in lots of explicit memory reference deletes, what you're writing is not C++ but C. A C++ codebase would use RRID and automatic memory management to obviate the need for any explicit memory management. My last C++ project at work contained zero (yes, zero) calls to delete/free() out of around 20000 lines of code and a year of development/testing.

You're making the same mistake you're accusing C++ developers of making - you're viewing C++ through Java lenses.

So use real-time Java

[shis-ka-bob]

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.

Not Oracle/Sun Yet

[fm6]

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.