Follow Slashdot stories on Twitter


Forgot your password?
Java Programming

Java Gets New Garbage Collector, But Only If You Buy Support 587

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?"
This discussion has been archived. No new comments can be posted.

Java Gets New Garbage Collector, But Only If You Buy Support

Comments Filter:
  • by gubers33 ( 1302099 ) on Friday May 29, 2009 @03:06PM (#28142125)
    Garbage collection is the process freeing objects that are no longer referenced by the program.
  • by MarkvW ( 1037596 ) on Friday May 29, 2009 @03:07PM (#28142137)

    I think garbage is allocated memory that is no longer needed.

  • by HBI ( 604924 ) on Friday May 29, 2009 @03:08PM (#28142173) Journal

    Java hides the details of memory allocation from the programmer. Objects, strings, etc use memory. When they are first used, Java makes sure that the appropriate amounts of memory are allocated for the item in question. When these items are no longer in use, the garbage collector finds them and frees the memory so that it can be used for other parts of the application.

    VB is another place where a garbage collector would be found. Ditto .NET.

  • by Anonymous Coward on Friday May 29, 2009 @03:10PM (#28142199)

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

  • by morgan_greywolf ( 835522 ) on Friday May 29, 2009 @03:14PM (#28142283) Homepage Journal

    Okay, here's a better description: garbage collection is a means of freeing memory by cleaning out old objects (variables, buffers, data structures, code, etc.) the program doesn't need anymore.

    Example: I open a file in an application and work with it. While working with it, the programs allocates buffers (temporary holding places) and data structures and so forth in memory. When I'm done, I close the file. The application needs no longer needs all this data associated with the file, so it calls garbage collection routines to free them up.

  • by forkazoo ( 138186 ) <> on Friday May 29, 2009 @03:14PM (#28142287) Homepage

    As a non-programmer, can someone give a brief explanation of what a garbage collector is as it pertains to programming.

    C++ has two important keywords: "new" and "delete." You use new when creating an object, and when you are done with it, you use delete to free up the memory it was using. (And, depending on the object, it may do some special stuff while being deleted, like close network sockets, or write a log entry about how sad being deleted is.)

    Java has a concept of "new," but it doesn't have a "delete." (Well, the concept exists behind the cutain, but programmers never delete things themselves when using Java.) Java assumes that you are more interested in creating stuff, and don't want to be bothered with the minutia of getting rid of it when you no longer care about it. So, the Java run time goes around deleting stuff that seems like it is no longer being used. (Reference count indicates it can no longer be used.) This is called garbage collection. It's a surprisingly tricky, and nuanced process to figure out when stuff should be deleted. You want to be pretty prompt in deleting stuff that is no longer used so it doesn't sit around using memory for no reason. But, you don't want your garbage collector to be so manic about cleaning things up that the actual program doesn't get enough CPU time to get anything done. You also want a garbage collector to be fairly predictable. It's great if it usually has a low overhead, but terribly if it occasionally goes insane and locks everything up for three minutes under some use cases.

    This new garbage collector is a little more sane, a little quicker and a little less manic. For many well written programs, the difference won't be that huge because they shouldn't creating and abandoning enough stuff for garbage collector to really matter. At least, that's my assumption. If I ever actually meet a well written program, I'll be able to verify that. :)

  • by KeithIrwin ( 243301 ) on Friday May 29, 2009 @03:20PM (#28142369)

    When computer programs need to keep track of information, they store it in the computer's memory. The information they store is generally arranged into structures. In object-oriented languages like Java, these structures are called objects. Every object has to have its own place in memory, called an address. Two different objects cannot use the same space in memory at the same time. When a program has a new object that it needs to create, it has to know where to put it. To do this, it uses a system which allocates some memory for it. When the program is done with the object, it should be deallocated so that the same memory can later be used for a different object. If objects are not deallocated when they are done being used, then the program will grow to take up more and more memory over time until the computer runs out of memory. This is called a memory leak.

    There are two main scheme for deallocating an object's memory once the program is done with it. Older programming languages use explicit memory deallocation, meaning that when the program is done with an object, it says so. This can unfortunately be somewhat problematic. If a program forgets to say that it's done with an object, then that object never gets deallocated and the program leaks memory. If the program says that it's done with an object when some other part of the program is still using the object, then a new object of a different type might be written over the old object but because the other part of the program doesn't know this has happened, all sorts of odd problems can occur.

    To solve this many newer languages including Java use a technique called garbage collection. In a garbage collecting language, the program does not explicitly say when it is done with an object. Instead the garbage collection system examines the cross-references between different objects to determine whether or not it is still possible for the program to use a particular object. If using it is impossible, then the system will deallocate it. In most systems, the garbage collection doesn't run continually swooping up every new bit of space the moment it becomes available, but instead just runs periodically clearing out anything which has become unusable since the last time it ran.

  • Re:Troll? (Score:3, Informative)

    by keithjr ( 1091829 ) on Friday May 29, 2009 @03:22PM (#28142419)
    Only if the article actually is a sensationalist piece of trolling. Sun is releasing an experimental feature to a subset of customers rather than the entire world. And Oracle does not own Sun yet, since the deal has not even been finalized, and therefore is not making decisions about Java.

    Slashdot, you disappoint me. Again.
  • by fatp ( 1171151 ) on Friday May 29, 2009 @03:23PM (#28142433) Journal
    It is the tradition of Oracle to distribute software with all functionality (including those separately licensed expensively) and let the user to make sure they don't use unlicensed features.
  • by bjourne ( 1034822 ) on Friday May 29, 2009 @03:25PM (#28142465) Homepage Journal

    A gc (garbage collector) is what programmers use instead of manually handling memory. In non-gc languages such as C programmers have to spend a lot of time being careful not to inadvertently create memory leaks. So programming in languages with gc is generally faster than in those without.

    The drawback is that memory is often handled less efficiently by the gc than by the programmer so the program becomes slower and uses more memory. However that depends on the quality of the gc. It is quite easy to write a gc, but that one probably will have awful performance. Writing a good is harder and takes more time. Writing one with performance that handles memory as good as a skilled programmer handling manual allocation is exceptionally hard and requires man-years in effort.

    It's like a chess engine, most programmers can write one but if you want one that can match a human or even Big Blue then you need to spend some time on it. So from Oracles perspective, it very much makes sense to try and monetize their high performance gc even if it's a shitty move overall. Most chess players has no use for a chess engine stronger than grandmaster level. But there are professional players out there who has a genuine need for a more challenging chess engine and would pay good money for it. In a similar vein most Java programmers can live with the default gc, but some big enterprises will feel they need a better one and pay lotsa $$$ for it even if the performance gain is only 5-10%.

  • by TeaCurran ( 575365 ) on Friday May 29, 2009 @03:28PM (#28142509) Homepage
    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.
  • Re:Almost (Score:4, Informative)

    by 3p1ph4ny ( 835701 ) on Friday May 29, 2009 @03:30PM (#28142529) Homepage

    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.

  • by publiclurker ( 952615 ) on Friday May 29, 2009 @03:30PM (#28142535)
    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.
  • by rdavidson3 ( 844790 ) on Friday May 29, 2009 @03:34PM (#28142589)
    Programming in C gives you more control over managing memory, but the price comes if the programmer is not careful about collecting the garbage up afterwards and you'll end up with the application taking more and more memory and your computer will eventually starting slowing down and could start complaining about not enough memory.
  • by mikael ( 484 ) on Friday May 29, 2009 @03:36PM (#28142633)

    When you create objects to represent information consisting of things like character strings, arrays, lists and hierarchical trees, you make a system call to create a new list of data objects.

    In languages like 'C', this would be like 'malloc( number of bytes) ' or 'calloc( number of bytes)'. You would then have to match every such call with an equivalent 'free( pointer)' to ensure the memory was freed. Failure to do so leads to 'memory leaks' where the memory space is allocated but incorrectly freed (caused by uninitialised pointer variables, missing calls or faulty decision making).

    C++ tried to fix this by having 'new' and 'delete' operators which were intended to be called through the constructor (a function automatically called with the object is created) and the destructor (a function automatically called when the object is destroyed). However, there were times when these functions also needed to be called throughout the lifetime of the object, so memory leak problem crept in again.

    JAVA attempts to fix C++ by eliminating the need for the 'delete' operator. Since every function always belongs to a class, and consequently a data object, data always belongs to a data object. Memory is allocated as before, but when a data object ceases to be in use (return of a function call), it is placed in the garbage area. At periodic intervals, the garbage collector is called and all the allocated memory blocks are collected and freed. The disadvantage is that an application could build up a large amount of "garbage memory" and could freeze for several seconds while this process occurred.

  • by samweber ( 71605 ) on Friday May 29, 2009 @03:36PM (#28142635)

    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.

  • Re:Almost (Score:5, Informative)

    by TheRaven64 ( 641858 ) on Friday May 29, 2009 @03:38PM (#28142651) Journal
    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.
  • by hibiki_r ( 649814 ) on Friday May 29, 2009 @03:41PM (#28142689)

    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.

  • Re:No malloc( )s (Score:3, Informative)

    by kailoran ( 887304 ) on Friday May 29, 2009 @03:43PM (#28142713)
    Not only did you not get the joke, you also have some misconceptions about how the Java GC works. There is no counter, instead the program state is analysed for unreachable objects. Also, memory is not freed immediately, but some unspecified time later (i.e. during the next GC cycle)
  • by cneth ( 718384 ) on Friday May 29, 2009 @03:44PM (#28142741)
    Oracle does not yet own Sun and can't (yet) set business direction for it. It's just a new, experimental feature, folks.
  • by jeanph01 ( 700760 ) on Friday May 29, 2009 @03:48PM (#28142791)
    Here [] 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.
  • Re:Seriously Java? (Score:5, Informative)

    by maxume ( 22995 ) on Friday May 29, 2009 @03:56PM (#28142909)

    Java and Javascript are only nearly identical in that they both contain Java in their names.

    Javascript is much closer to Ruby than it is Java (but the built in objects aren't generally as rich, and people scream and whine about the prototype based object system).

  • Re:Seriously Java? (Score:4, Informative)

    by turgid ( 580780 ) on Friday May 29, 2009 @04:08PM (#28143073) Journal

    Please provide me one example of a free/OSS platform implementation of a commercial product that is inarguable BETTER than the original proprietary version

    Linux > Unix.

  • Re:Seriously Java? (Score:2, Informative)

    by Anonymous Coward on Friday May 29, 2009 @04:14PM (#28143167)

    It gets better. (Or worse, depending on your point of view.)

    This version also adds a blacklist to the JRE, so Oracle can ban people from running various applications.

    Just what I want to do, give Oracle the power to randomly stop applications I use from running. I wonder how long it will take for Eclipse to "accidentally" make it onto the blacklist?

    Oh stop.

    Support for blacklisting signed jar files has been added to 6u14. A blacklist is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications. A system-wide blacklist will be distributed with each JRE release. Java Plugin and Web Start will consult this blacklist and refuse to load any class or resource contained in a jar file that's on the blacklist. By default, blacklist checking is enabled. The deployment configuration property can be used to toggle this behavior. .

    You guessed it - the blacklist applies to applications you can launch from untrusted sources. Go back to thy cave, troll.

  • by Thomasje ( 709120 ) on Friday May 29, 2009 @04:17PM (#28143199)

    Is there no way to copy the bitwise contents of a pointer into an int in Java, then later copy it back?


    I find it unrealistic to think that you could prevent deliberate "dangling pointers". That kind of security is what hardware-level memory management is about.

    ...and the Java security just does what it takes to provide that kind of security on devices where hardware memory management is not available.

    Also, if you do deallocations (or close file handles, or free locks or other resources) in destructors of man classes, you eventually screw up, and get a memeory leak every few thousand lines of code.

    True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak... Which is why using a memory analyzer is a good idea *even* in GC environments.

  • It's in OpenJDK too (Score:5, Informative)

    by arthurp ( 1250620 ) on Friday May 29, 2009 @04:19PM (#28143213)
    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.
  • Re:Seriously Java? (Score:4, Informative)

    by shutdown -p now ( 807394 ) on Friday May 29, 2009 @04:19PM (#28143217) Journal

    This version also adds a blacklist to the JRE, so Oracle can ban people from running various applications.

    It's not nearly as sinister as it sounds, at least judging by release notes:

    "Support for blacklisting signed jar files has been added to 6u14. A blacklist is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications. A system-wide blacklist will be distributed with each JRE release. Java Plugin and Web Start will consult this blacklist and refuse to load any class or resource contained in a jar file that's on the blacklist. By default, blacklist checking is enabled. The deployment configuration property can be used to toggle this behavior."

    So it's opt-out, but configurable. You're still free to run whatever you want.

  • by kumanopuusan ( 698669 ) <goughnourc AT gmail DOT com> on Friday May 29, 2009 @04:25PM (#28143287)
    Just click on the "change" button after the summary and the comment subjects display correctly. Whatever the problem is with the cached story pages, is fine.
  • by jeremyp ( 130771 ) on Friday May 29, 2009 @04:41PM (#28143485) Homepage Journal

    As a beer drinker, I drink lots of beer. When I was a C++ programmer, I had to make sure I threw away my empty beer cans after drinking the beer. Unfortunately, occasionally, I forgot to do that and pretty soon my room would fill up with empty beer cans so that I couldn't get to the fridge to get more beer out of it.

    However, now I am a Java programmer and I have a servant (a beer can collector) who comes around and clears up the beer cans for me every now and again. I no longer have to worry about throwing them away myself.

  • Re:Seriously Java? (Score:1, Informative)

    by Anonymous Coward on Friday May 29, 2009 @04:48PM (#28143581)
    did you think of

  • by shutdown -p now ( 807394 ) on Friday May 29, 2009 @04:48PM (#28143585) Journal

    Most such languages have an "out" somewhere, so that you can use the language to call C system APIs, or use device-mapped hardware, because that's all that commercial software *did* in the olden days.

    In case of Java it's native methods / JNI. However, it's still not on JVM level - Java can only declare some method as native, it's the JNI spec that defines how such a method could be implemented in C. However, a JVM can refuse to execute native methods, and does so when running sandboxed (e.g. as an applet). But it still needs to manage memory for all the sandboxed code in a guaranteed-safe way, hence the need for GC.

    On the other hand, .NET has the full bunch right in the VM - raw data & function pointers with arithmetic, explicit arbitrary-layout structs (which include unions as a subset), etc. But it also divides all opcodes into "verifiable" (meaning no statically-uncheckable pointer trickery) and "unverifiable", and does not execute methods containing unverifiable code when sandboxed. So it also needs GC for verifiable code.

  • by Verdatum ( 1257828 ) on Friday May 29, 2009 @04:53PM (#28143651)
    No, the old, old garbage collector was rubbish. Java has been taking crap for it ever since, even though it changed garbage collecting mechanisms ages ago.

    From performance:

    "The 1.0 and 1.1 Virtual Machines used a mark-sweep collector, which could fragment the heap after a garbage collection. Starting with Java 1.2, the Virtual Machines switched to a generational collector, which has a much better defragmentation behaviour. [2] Modern Virtual Machines use a variety of techniques that have further improved the garbage collection performance.[10]"

  • Re:Seriously Java? (Score:4, Informative)

    by wed128 ( 722152 ) <.woodrowdouglass. .at.> on Friday May 29, 2009 @04:54PM (#28143669)

    It's all a fad.

    Soon we'll be back to paper tape and punchcards. damn whipper-snappers with your fancy garbage collection.

  • Re:Seriously Java? (Score:4, Informative)

    by flydpnkrtn ( 114575 ) on Friday May 29, 2009 @05:08PM (#28143887)

    This is a very common misconception (at least in my humble experience...)

    Javascript was born at Netscape at a time when the buzzword Java was cool and hip... it really should be called EMACSscript but that's not cool and hip enough

    From the Wikipedia article:
    'JavaScript, despite the name, is essentially unrelated to the Java programming language even though the two do have superficial similarities. Both languages use syntaxes influenced by that of C syntax, and JavaScript copies many Java names and naming conventions. The language's name is the result of a co-marketing deal between Netscape and Sun, in exchange for Netscape bundling Sun's Java runtime with their then-dominant browser. The key design principles within JavaScript are inherited from the Self and Scheme programming languages.

    "JavaScript" is a trademark of Sun Microsystems. It was used under license for technology invented and implemented by Netscape Communications and current entities such as the Mozilla Foundation."'

  • by gbjbaanb ( 229885 ) on Friday May 29, 2009 @06:45PM (#28145003)

    good analogy - except you forgot some important bits:

    1. you have to ensure you drink all the beer, and not leave any in the can, or the servant will give it a little shake, and think "masters not finished with this one yet, I'd best leave it".

    2. You are never surrounded by a clean room, there are always empty beer cans lying around waiting for the servant to collect them.

    Now, as a C++ drinker, I have a mechanism that help out, every time I go to the fridge to get a beer, I pour it into the glass object and throw the can away immediately - thus never having empty cans lying around, when the glass is empty, I refill and find the empty can problem is a non-issue. (that's such a convoluted analogy for RAII!)

  • Re:Seriously Java? (Score:5, Informative)

    by SplashMyBandit ( 1543257 ) on Friday May 29, 2009 @08:20PM (#28145787)

    You're a funny guy but obviously have zero idea about what you are talking about. It's a bit aggravating that ignorant folk still come out with the same old 'slow' mantra and unfortunately even more ignorant folk buy into it. That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).

    I used to eschew Java for the speed of C++ but now I've completely switched to Java for most development tasks (apart from some C glue-code [JNI] when I need to integrate some scientific instrument or another). I'm doing instrument control, image processing and analysis and I need both reasonable latency, multithreading support, and every performance cycle I can get, and yet Java is plenty fast enough for me (and even embedded devices these days have relatively large amounts of RAM this is far less of an issue than it used to be).

    Seriously Java is very fast these days. Graphics2D is all done in Direct3D or OpenGL shaders, the VM is very optimised and quite often approaches FORTRAN (which is faster than C). Don't believe me? check out the links below.

    So please, next time stop with the FUD (that used to be marginally true 5 years ago) and start with an open mind.

    • From []
      "However, High Performance Computing applications written in Java have recently won benchmark competitions. In 2008, Apache Hadoop, an open source High Performance Computing project written in Java was able to sort a terabyte of integers the fastest.[46]"
    • INRIA (French scientifc Institution) report on High Performance Computing with Java [Summary: Java approaching FORTRAN for speed, although some network intensive speed bumps still remaining] []
    • From []
      Current State of Java for HPC

      At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3]

"Never give in. Never give in. Never. Never. Never." -- Winston Churchill