Forgot your password?
typodupeerror
Java Programming

Java's New G1 Collector Not For-Pay After All 171

Posted by kdawson
from the trial-balloon-popped dept.
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."
This discussion has been archived. No new comments can be posted.

Java's New G1 Collector Not For-Pay After All

Comments Filter:
  • Right path? (Score:5, Funny)

    by DoofusOfDeath (636671) on Friday June 05, 2009 @09:10AM (#28221165)

    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!

    • 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?

      You must be new here.

  • But it could be! (Score:5, Insightful)

    by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Friday June 05, 2009 @09:10AM (#28221171)

    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! (Score:4, Informative)

      by yacc143 (975862) on Friday June 05, 2009 @09:26AM (#28221335) Homepage

      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! (Score:5, Informative)

        by tepples (727027) <tepples@gmaiBLUEl.com minus berry> on Friday June 05, 2009 @09:39AM (#28221517) Homepage Journal

        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.

      • by Late Adopter (1492849) on Friday June 05, 2009 @09:53AM (#28221705)

        Nor are destructors called on longjmp.

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

        • by abdulla (523920)
          There are also situations that force your hand. If you're using a C library, and you provide it callbacks, if the library wasn't compiled with exception handling support (very rare for C libraries to be on Linux), then you're out of luck. If you throw an exception your whole program fails, you have to longjmp() to a safe point inside your C++ code from where you can throw. I find I have this happen a lot with image libraries, e.g.: libpng and libjpeg.

          Best solution is to have all your objects set up befor
      • Re:But it could be! (Score:5, Informative)

        by mpsmps (178373) on Friday June 05, 2009 @10:47AM (#28222427)

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

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

    • by siloko (1133863) on Friday June 05, 2009 @09:32AM (#28221421)

      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?

    • Give me deterministic behavior over faster GC any day.

      The thing is, there really is no middle ground. You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope. The good news is that a modern generational garbage collector is optimized toward collecting younger objects, so it's fairly likely that your resource objects will be collected fairly soon after you're done using them. .NET provides a modicum of determinism with a bunch of s

      • C++ doesn't have heap compaction

        There are ways around this, such as the buddy heap [wikipedia.org] and the Windows XP low-fragmentation heap [microsoft.com], which round sizes up to a power of 2 and keep similarly-sized allocations together.

        • by owlstead (636356)

          With C++ there is always a way to get (around) a feature. The trick is to let these tricks play nice with the rest of your pogram including the used libraries and different runtime environments.

          • by tepples (727027)

            The trick is to let these tricks play nice with the rest of your [program] including the used libraries and different runtime environments.

            That's an issue with any std::malloc replacement, but this page [stackoverflow.com] claims that Firefox manages to work around it.

    • Java doesn't fail (Score:5, Informative)

      by beldraen (94534) <.chad.montplaisir. .at. .gmail.com.> on Friday June 05, 2009 @10:15AM (#28221989)

      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.

      • by hibiki_r (649814)

        But in C++, many programs don't really deal with resource deallocation directly: That's what reference counting pointers are for. The resources get wiped the moment nothing references them anymore, and we can release both memory and connections at the exact moment they are not used anymore. In Java, just as you said, we end up doing it explicitly, doing a lot more work by hand, and risking destroying a resource that someone still has a reference to.

        Sure, the code can still work, but it's a lot harder to get

      • Re: (Score:3, Insightful)

        by deepestblue (206649)

        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.

      • by skeeto (1138903)

        This means that a resource, other than memory, can't be tied completely to an object. Anything using the object has to handle the resource manually, like basic C++ memory management, breaking the abstraction.

        For example, I might want to tie, say, a database to an object. I create the object which opens/creates a database. I then use the object normally, and it makes transactions with the database as needed, but since finalize() is not reliable I have to explicitly call a close() method before I let the obje

      • by Alef (605149)
        The problem is that you can't do what you were doing before, just by not calling it finalize. In C++ it is a common practice to rely on the stack for resource management (this is where it differs from C), and the reason that you can do this is because you have destructors. And yes, you can do this even when you allocate on the heap (see scoped_ptr [boost.org]). There is no equivalent way to track resources in Java.

        Now, you might say that this is not an issue, since the GC will reclaim all memory anyway. But what you
      • Yeah, I remember reading up on finalization before I even knew Java's syntax. I decided to create a method in every class - "deleteMe", which nulls everything out when called.

        I'm sure the garbage collector cleans it up soon after. Good enough. Has worked fine ever since.

    • by owlstead (636356)

      Amazingly boring? Jeez, there is a lot of ways of doing garbage collection. You can mix GC types, have multiple levels of GC, heap sizes to tweak for these levels etc. Java has got an upper limit to the amount of memory the process uses, but I can think of other schemes that dont. Then you can do a lot of multithreading stuff, but you cannot break code anytime, because in that case the whole VM can die unexpectedly. Then you have to choose when and how long to garbage collect, if you only do so if CPU utili

    • by shis-ka-bob (595298) on Friday June 05, 2009 @11:21AM (#28222965)
      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.
    • by againjj (1132651)

      Garbage collection is an amazingly boring field of computer science.

      And so is , unless it isn't. Any time some one says, "X is boring," or, "X is interesting," that really means, "X is boring TO ME," or, "X is interesting TO ME." "Boring" or "interesting" is opinion. Personally, I find GC rather interesting, in particular the latest advances in real-time GC. I did compiler/programming languages work for my M.S., and I believe that most people would think that it is boring as well, but it is not to me.

      It's all about tracking references

      There is a lot more than that.

    • For every article, opinion and comment that starts with:

      "Where Java really fails..."

      I add to my 'what-evar!' list, consider the rant it in my app design and continue programming my [insert ANY app here] in Netbeans (likelt the app that pays my mortgage).

      .

      Thanks for the [usual academic] opinion.

      On the flip side, Java says, separate implementation representation (i.e. low-level, on the metal, specific to vendor, dependencies, etc...) from logical representation (move robot arm 10 degrees). That forc

    • by ADRA (37398)

      I think you're looking at deterministic in a different way than I. I know that when there are no longer any references to an Object, that object is completely out of scope from my application. I don't care how the system I'm on cleans it up, the same way that 99% of the time, you don't care about what a free/delete/close really does behind the scenes. What does matter is that:
      1. The process of cleaning up this memory doesn't negatively impact the application's runtime performance

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

      So? I switched from C/C++ to Java over 10 years ago, and have not once needed to even consider implementing finalize. The only thing this "lack of deterministic behavior" really means in practice is that you have to explicitly close input/output streams, rather than let objects go out

      • Re: (Score:3, Insightful)

        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 man

        • I'm not familiar with smart pointers; I can't tell (or remember) if they were always possible or if they were a language feature added since I last coded C++ in the mid-90s.

          They do seem cool and a better solution for this problem. But it seems you are still stuck with implementing them yourself, in which case you are in [almost] the same situation as in Java. I.e. in C++ you have to write custom code (e.g. smart pointers) to do the resource freeing automatically; but in Java you can do the same thing b
          • Re: (Score:3, Informative)

            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.

        • by countach (534280)

          Smart pointers are an essentially reference counting solution, with all its pitfalls. I don't doubt it works in 90% of scenarios, but when things get really complicated, things can get hairy.

    • by countach (534280)

      I don't find it boring, but then I am geeky.

    • by maraist (68387) *

      Wow, I've done a lot of Java development and have never had a need for a finalizer. So while you may have a niche need in your C++/Java work, you certainly don't represent a majority of use-cases, and thus I can disregard your claim of Java's failure. There are many many other programming paradigms for resource cleanups. try-catch-finally (or better yet, pass a runnable to try-catch-finally processor to guarantee consistent resource-management). One particularly elegant form is Thread-Local Transactions

  • Well.... (Score:4, Insightful)

    by samriel (1456543) on Friday June 05, 2009 @09:12AM (#28221201)
    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 (Score:5, Informative)

    by RPoet (20693) on Friday June 05, 2009 @09:15AM (#28221221) Journal

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

    • Re: (Score:3, Insightful)

      by Joehonkie (665142)
      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.
      • by causality (777677) on Friday June 05, 2009 @09:54AM (#28221715)

        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

      • People were so buy foaming at the mouth that they never bothered to read the actual article

        But but but! Oracle is eviiiiiiiiiiiil! Who cares what the truth was? Did you know that Oracle was eviiiiiiiiiiiiiiiiiiiiiiiil!

    • Re: (Score:3, Insightful)

      by BikeHelmet (1437881)

      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!

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

  • by petermgreen (876956) <plugwashNO@SPAMp10link.net> on Friday June 05, 2009 @09:20AM (#28221275) Homepage

    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.

    • by ebuck (585470)

      I tend to agree. If they really wanted a pay-to-use-this garbage collector, then they would have made the garbage collector a upgrade or add-on to the existing JVM and not distributed it in it's fully functional form for free.

      Fully functional software tends to get used, and Oracle is not such a newbie to think that a piece of paper (or an electronic equivalent of that) will block use of a revenue generating item all by itself. Nor are they interested in auditing and suing everyone who might have a product

  • No Way! (Score:5, Funny)

    by Anonymous Coward on Friday June 05, 2009 @09:24AM (#28221313)

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

  • by Lemming Mark (849014) on Friday June 05, 2009 @09:26AM (#28221341) Homepage

    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 (Score:5, Insightful)

    by harryandthehenderson (1559721) on Friday June 05, 2009 @09:46AM (#28221595)

    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 (Score:4, Informative)

    by javacowboy (222023) on Friday June 05, 2009 @09:51AM (#28221665)

    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.

    • by owlstead (636356) on Friday June 05, 2009 @10:51AM (#28222491)

      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: (Score:3, Insightful)

        by againjj (1132651)
        In other words, Java is not one-size-fits-all, and all languages have tradeoffs.
      • 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.

        It's surprising. Why would operations on bytes (or machine words) in Java be any slower than in C? After all, the JIT will compile them to the same stuff as a C compiler would do, and Java HotSpot is widely recognized as the most sophisticated JIT in production out there.

        So far as I know, most of Java slowness doesn't actually come from bit twiddling being slow. It's because of things like all calls being virtual by default, and all objects being allocated on heap and not stack by default (yes, I know Java

      • by ADRA (37398)

        Things like Cryptography and Compression which are process intensive are already implemented in native hooks in the base JVM. For instance, if you're using a GZIPOutputStream to GnuZip compress your data, the actually compression is done in a native block. Just because -a part- of your code requires high thoughtput, it doesn't mean that the entire piece of code needs to be developed in said language. Think of it like the distinction between C and ASM. You'd never write your entire code in assembly anymore,

    • 1) Java is slow
      Semi-true, java is what you get when you take a language that is slow by design and optimise the hell out of it. Overall perforamnce is reasonable but not brilliant (shootout.alioth.debian.org places it at arround 1.5 to 2 times slower than C). Predictability of performance can be a problem though because instanciating a new class can mess with the inheritance tree and hence the performance of seemingly unrelated code.

      2) Java is not yet open source (or only parts of it are or isn't "really" o

      • by countach (534280)

        I would hardly call Java slow by design. TCL or Bourne shell would be slow by design. It seems like C programmers, and C-like language programmers think everything except C and its ilk to be "slow by design".

  • Well, the keys are right next to each other...

    By the way, the research paper describing G1 is here [sun.com].

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

  • 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...
    • by tthomas48 (180798)

      Uh. Sure. This will be a problem when Microsoft makes .Net run well on Linux. Until then they'll just be that really obnoxious loud truck rumbling in the next lane over.

      I have no idea what you mean by SQL Server being ahead of Oracle, but SQL Server also only runs on Microsoft OSes and is thus only useful for people who run Microsoft OSes.

    • by afidel (530433)
      The only way that I see SQL server ahead in is pricing. When we implemented Oracle 10gR2 about 3 years ago we got such good pricing out of Oracle that MS refused to match for SQL Enterprise. Now that quad core is the norm and 8 core is on the horizon Oracles per core pricing model is insane.
    • basically letting Microsoft get ahead with SQL Server in many respects

      True. This [xkcd.com] only works in SQL Server, not Oracle.

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

  • Not Oracle/Sun Yet (Score:5, Informative)

    by fm6 (162816) on Friday June 05, 2009 @12:04PM (#28223653) Homepage Journal

    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.

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

      That's a laugh. At the operational level, Oracle will not interfere much until the acquisition is approved.

      But at the strategic level? You can bet your bottom dollar that Sun isn't blowing its nose without checking with Oracle to see if it's OK first.

  • 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?

Save the whales. Collect the whole set.

Working...