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

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

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

    by harryandthehenderson (1559721) on Friday June 05, 2009 @09:36AM (#28221465)
    Actually the original article was posted by ScuttleMonkey, but both are masters at spreading misleading, FUD-filled articles.
  • Re:But it could be! (Score:3, Informative)

    by tepples (727027) <tepples@nOSpAM.gmail.com> on Friday June 05, 2009 @09:36AM (#28221479) Homepage Journal

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

    by tepples (727027) <tepples@nOSpAM.gmail.com> 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.

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

  • Re:But it could be! (Score:1, Informative)

    by Anonymous Coward on Friday June 05, 2009 @09:59AM (#28221785)
    Objective C (cocoa/openstep) reference counting does not have cycle detection.
  • Java doesn't fail (Score:5, Informative)

    by beldraen (94534) <chad.montplaisir@gm3.14ail.com minus pi> 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.

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

    by Ethanol-fueled (1125189) on Friday June 05, 2009 @10:18AM (#28222017) Homepage Journal
    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! (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).

  • Re:But it could be! (Score:3, Informative)

    by hibiki_r (649814) on Friday June 05, 2009 @11:01AM (#28222641)

    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.

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

  • Re:But it could be! (Score:3, Informative)

    by shutdown -p now (807394) on Friday June 05, 2009 @01:47PM (#28225259) Journal

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

    by shutdown -p now (807394) on Friday June 05, 2009 @02:29PM (#28225829) Journal

    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 [java.net] is one from Google). However, none of them were accepted for Java 7 (fools...).

  • Re:But it could be! (Score:3, Informative)

    by david_thornley (598059) on Friday June 05, 2009 @06:07PM (#28228103)

    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.

"You don't go out and kick a mad dog. If you have a mad dog with rabies, you take a gun and shoot him." -- Pat Robertson, TV Evangelist, about Muammar Kadhafy

Working...