Are there any Garbage Collector improvements?

Discussion in 'Java' started by Mark Sizzler, Nov 14, 2008.

  1. Mark Sizzler

    Mark Sizzler Guest

    We have problems with the Java Garbage Collector.
    It is very slow when we hold large tables in memory and perform many inserts and updates.

    As far as I remember there are 3rd party improved garbagr collector products.
    Does someone have a recommendation?

    Are there any best practice hints on how to improve the Java built-in GC?

    Mark
     
    Mark Sizzler, Nov 14, 2008
    #1
    1. Advertising

  2. In article <491dca53$0$32682$-online.net>,
    (Mark Sizzler) wrote:

    > We have problems with the Java Garbage Collector. It is very slow
    > when we hold large tables in memory and perform many inserts and
    > updates.


    This makes me wonder if you are unintentionally retaining objects in a
    collection that implements the Map interface.

    [...]
    > Are there any best practice hints on how to improve the Java built-in GC?


    Avoid unintentional object retention and consider WeakHashMap:

    <http://java.sun.com/javase/6/docs/api/java/util/WeakHashMap.html>
    <http://www-128.ibm.com/developerworks/java/library/j-jtp11225/>
    <http://www.ibm.com/developerworks/java/library/j-perf08273.html>

    --
    John B. Matthews
    trashgod at gmail dot com
    http://home.roadrunner.com/~jbmatthews/
     
    John B. Matthews, Nov 14, 2008
    #2
    1. Advertising

  3. Mark Sizzler

    Lew Guest

    Mark Sizzler wrote:
    >> We have problems with the Java Garbage Collector. It is very slow
    >> when we hold large tables in memory and perform many inserts and
    >> updates.



    John B. Matthews wrote:
    > This makes me wonder if you are unintentionally retaining objects in a
    > collection that implements the Map interface.


    Other possibilities are references from long-lived objects to short-
    lived ones, and intentional retention of objects in the mistaken
    belief that it will reduce GC overhead.

    Mark Sizzler wrote:
    >> Are there any best practice hints on how to improve the Java built-in GC?


    John B. Matthews wrote:
    > Avoid unintentional object retention and consider WeakHashMap:


    Also avoid intentional retention of references.

    If the algorithm requires that an object live a long time, let it
    live. But an antipattern in Java is to keep an object and reuse it
    for different values over and over, e.g.,

    public class GcAntiPattern
    {
    public static void main( String [] args )
    {
    Foo foo = new Foo();
    for ( int ix = 0; ix < 10000; ++ix )
    {
    fillWithValues( foo );
    doSomethingWithFoo( foo );
    }
    }
    }

    Usually in such cases it is better to allocate the 'Foo' inside the
    loop so that it can be GCed by a minor collection instead of a major
    one.

    > <http://java.sun.com/javase/6/docs/api/java/util/WeakHashMap.html>
    > <http://www-128.ibm.com/developerworks/java/library/j-jtp11225/>
    > <http://www.ibm.com/developerworks/java/library/j-perf08273.html>


    Also:
    <http://www.ibm.com/developerworks/java/library/j-jtp09275.html>
    <http://www.ibm.com/developerworks/java/library/j-jtp01274.html>

    --
    Lew
     
    Lew, Nov 14, 2008
    #3
  4. Mark Sizzler

    Daniel Pitts Guest

    Mark Sizzler wrote:
    > We have problems with the Java Garbage Collector.
    > It is very slow when we hold large tables in memory and perform many inserts and updates.
    >
    > As far as I remember there are 3rd party improved garbagr collector products.
    > Does someone have a recommendation?
    >
    > Are there any best practice hints on how to improve the Java built-in GC?
    >
    > Mark

    Don't hold large tables in memory :)
    Are you sure its the garbage collector? Have you tried tuning the
    performance parameters:
    <http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html>


    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Nov 14, 2008
    #4
  5. Mark Sizzler

    Lew Guest

    Lew wrote:
    >> If the algorithm requires that an object live a long time, let it
    >> live. But an antipattern in Java is to keep an object and reuse it
    >> for different values over and over, e.g.,
    >>
    >> public class GcAntiPattern
    >> {
    >> public static void main( String [] args )
    >> {
    >> Foo foo = new Foo();
    >> for ( int ix = 0; ix < 10000; ++ix )
    >> {
    >> fillWithValues( foo );
    >> doSomethingWithFoo( foo );
    >> }
    >> }
    >> }
    >>
    >> Usually in such cases it is better to allocate the 'Foo' inside the
    >> loop so that it can be GCed by a minor collection instead of a major
    >> one.


    John B. Matthews wrote:
    >>> <http://java.sun.com/javase/6/docs/api/java/util/WeakHashMap.html>
    >>> <http://www-128.ibm.com/developerworks/java/library/j-jtp11225/>
    >>> <http://www.ibm.com/developerworks/java/library/j-perf08273.html>


    Lew wrote:
    >> Also:
    >> <http://www.ibm.com/developerworks/java/library/j-jtp09275.html>
    >> <http://www.ibm.com/developerworks/java/library/j-jtp01274.html>


    Avinash Ramana wrote:
    > In the case of that anti-pattern...
    >
    > Can you elaborate a little more on why the anti-pattern is bad? Why
    > is reusing an object bad? Is it worse than creating an object in a
    > loop like that?


    The referenced links explain it better than I probably can, but the key is
    that Java uses a generational garbage collector. Young generation collections
    are very fast, and object creation is blazingly fast. Tenured generation
    collections take much longer. Also, the JVM can often optimize away object
    creation altogether with temporary short-lived objects, depending on their
    shape and usage. Basically, as one of the cited articles point out, the
    programmer usually cannot do better than the compiler in Java.

    This is only a rule of thumb. It could be that creation of umpty-gazillion
    objects inside the loop would trigger so many young-generation GC cycles that
    it would help to create one outside the loop. Or, Hotspot might figure that
    out for you. It's hard to tell.

    That is the crux. We as programmers really don't know. It's better to scope
    a variable for its natural life - if an object is only used inside the loop,
    declare it inside the loop. This will prevent bugs that would be much, much
    worse than a putative, unprovable slowdown due to GC.

    --
    Lew
     
    Lew, Nov 15, 2008
    #5
  6. Mark Sizzler

    Tom Anderson Guest

    On Fri, 14 Nov 2008, Mark Sizzler wrote:

    > We have problems with the Java Garbage Collector. It is very slow when
    > we hold large tables in memory and perform many inserts and updates.
    >
    > As far as I remember there are 3rd party improved garbagr collector
    > products. Does someone have a recommendation?
    >
    > Are there any best practice hints on how to improve the Java built-in
    > GC?


    I'm not aware of any way to plug a third-party GC into Sun's JVM. You
    could switch to using another JVM - IBM make a good one, but i'm not aware
    of any more which are anywhere near as good. They're mostly research VMs,
    or fairly basic open-source ones. AFAIK, anyway.

    However, there are a lot of flags you can use to tune the way Sun's GC
    works. This guide discusses the most important stuff:

    http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

    Googling for things like 'java garbage collection tuning' will find you
    more.

    tom

    --
    We do what we must because we can.
     
    Tom Anderson, Nov 15, 2008
    #6
  7. Mark Sizzler

    Arne Vajhøj Guest

    Tom Anderson wrote:
    > I'm not aware of any way to plug a third-party GC into Sun's JVM. You
    > could switch to using another JVM - IBM make a good one, but i'm not
    > aware of any more which are anywhere near as good. They're mostly
    > research VMs, or fairly basic open-source ones. AFAIK, anyway.


    BEA and Oracle have their own JVM's too (Oracle owns BEA now, but
    I don't think they have merged product lines yet).

    BEA JRockIt has a very good reputation.

    Arne
     
    Arne Vajhøj, Nov 15, 2008
    #7
  8. Mark Sizzler

    J. Davidson Guest

    Lew wrote:
    > Other possibilities are references from long-lived objects to short-
    > lived ones, and intentional retention of objects in the mistaken
    > belief that it will reduce GC overhead.


    The garbage collector used to be very different.

    Old Java garbage collectors like mark-sweep had to do work in proportion
    to the number of dead objects. So to make code run fast you reused
    objects and avoided discarding too many.

    The relatively new generational garbage collector has to do work in
    proportion to the number of surviving objects instead. So to make code
    run fast you now should discard objects rather than retain them.

    GC optimization has basically been turned 180 degrees and stood up on
    its head by this. The advice to get the fastest GC performance now is
    diametrically opposite what was best with the older GC.

    If Mark is working with a Java project with very many tree-rings in it,
    it's quite likely the thing was coded exactly as horribly as possible
    from the stand-point of GC optimization, because of GC-optimization.

    Unfortunately, making it run fast with the newer GC means a lot of work
    or even a total rewrite of big chunks of it in that case. On the plus
    side, the results will be well worth it, making everything far faster
    than the old code used with the older GC. And it's very unlikely that
    the next big revolution in GC will flip everything over again, so the
    new code will be future-proofed in one respect that the old code
    (obviously) wasn't.

    Another good reason is that treating most objects as disposable can
    greatly simplify a lot of the logic, getting rid of pools and other
    scaffolding and allowing some of them to be made immutable, which lets
    you get rid of setters and possibly a lot of other code. Code that had
    to be maintained, and might contain bugs, as well as was bloating up the
    size of the running image and the jar files, bloating up the
    documentation, and cluttering up the IDE's method listing and code view.

    You can also afford to make classes that encapsulate a few primitives
    where you might have once just used the primitives directly to cut down
    on object creation. To use a worn-out old example, you can get rid of
    all those xs and ys worked on in tandem and use Point2D or Complex or
    whatever fits the situation without all those used-up Point2Ds or
    Complexes gumming up the garbage collector the way they would have, five
    or ten years ago. The code might get more readable, simpler, and less
    error-prone.

    Or you might just end up wishing for operator overloading to be in Java
    7. :)

    - jenny
     
    J. Davidson, Nov 17, 2008
    #8
  9. Mark Sizzler

    Tom Anderson Guest

    On Mon, 17 Nov 2008, J. Davidson wrote:

    > Lew wrote:
    >> Other possibilities are references from long-lived objects to short-
    >> lived ones, and intentional retention of objects in the mistaken
    >> belief that it will reduce GC overhead.

    >
    > The garbage collector used to be very different.
    >
    > Old Java garbage collectors like mark-sweep had to do work in proportion to
    > the number of dead objects.


    I don't think that was ever true. Mark-and-sweep and stop-and-copy both do
    work proportional to the number of live objects - dead objects are never
    reached during traversal of the object graph, and never touched.

    I think only C-style memory managers, which put each deleted block on a
    free list, do work proportional to dead objects.

    Rather, what it was that the pre-generational collectors would do work
    proportional to the *total* number of live objects on every collection,
    whereas generational collectors do work proportional to the number of live
    objects *in the nursery* (roughly). That meant that if you had a
    significant amount of long-lived objects (which most apps do), you wanted
    to avoid frequent collections, because each one would walk all your
    objects, and thus ...

    > So to make code run fast you reused objects and avoided discarding too
    > many.


    Bingo.

    > GC optimization has basically been turned 180 degrees and stood up on
    > its head by this. The advice to get the fastest GC performance now is
    > diametrically opposite what was best with the older GC.


    Also bingo. This is why i shudder when i read things like this:

    http://lab.polygonal.de/2008/06/18/using-object-pools/

    Right now, Flash has a pretty basic collector, and object pooling is
    apparently a very big win. At some point in the next few years, it'll get
    a more sophisticated collector (along with a JIT and all the other goodies
    needed to keep up with javascript), and then there's an excellent chance
    that all this stuff will end up being a big smoking hole in everyone's
    feet.

    With any luck, there will be a small number of pool libraries in use, and
    they'll all be written so that they can be replaced with no-op non-pooling
    versions when the time comes. Fingers crossed.

    tom

    --
    Due to my inability to deploy my Taser, I had to resort to punching him
    as hard as I could in the face. It is a taught technique. -- PC 5566,
    on the arrest of Yassin Omar
     
    Tom Anderson, Nov 17, 2008
    #9
  10. Mark Sizzler

    J. Davidson Guest

    Tom Anderson wrote:
    > I think only C-style memory managers, which put each deleted block on a
    > free list, do work proportional to dead objects.


    I recall reading about garbage collectors that did so as well. I
    definitely recall old Java versions performing better if you reused
    objects rather than discarded them -- exactly opposite to current Java.
    About the latter you seem to be in agreement.
     
    J. Davidson, Nov 21, 2008
    #10
  11. Mark Sizzler

    Tom Anderson Guest

    On Fri, 21 Nov 2008, J. Davidson wrote:

    > Tom Anderson wrote:
    >> I think only C-style memory managers, which put each deleted block on a
    >> free list, do work proportional to dead objects.

    >
    > I recall reading about garbage collectors that did so as well. I
    > definitely recall old Java versions performing better if you reused
    > objects rather than discarded them -- exactly opposite to current Java.
    > About the latter you seem to be in agreement.


    Yes, absolutely. I think this was due to their slow implementation of
    allocation, rather than their doing per-dead-object work. I think.

    tom

    --
    a moratorium on the future
     
    Tom Anderson, Nov 21, 2008
    #11
  12. Mark Sizzler

    Roedy Green Guest

    On 14 Nov 2008 18:58:27 GMT, (Mark Sizzler) wrote,
    quoted or indirectly quoted someone who said :

    >We have problems with the Java Garbage Collector.
    >It is very slow when we hold large tables in memory and perform many inserts and updates.


    Others will tackle your problem directly. Here are some things to
    check before you invest big bucks in new GC package.

    Have you instrumented to be sure the problem is GC? not the
    operations on the tables themselves?

    Does your table technique keep allocating new objects frequently? It
    should be doing something like ArrayList does, using a buffer bigger
    than needed and only growing it when it overflows.

    Have you done a study of the objects to make sure there is no
    packratting? No GC is going to work well if you accidentally hold on
    to objects you don't really need. see
    http://mindprod.com/jgloss/packratting.html

    Finally there is the ballerina in phone booth problem. What is your
    ratio of live object space to heap space? No GC will work well when
    that ratio gets too large.

    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    Your old road is
    Rapidly agin'.
    Please get out of the new one
    If you can't lend your hand
    For the times they are a-changin'.
     
    Roedy Green, Nov 21, 2008
    #12
  13. Mark Sizzler

    Tom Anderson Guest

    On Fri, 21 Nov 2008, Roedy Green wrote:

    > On 14 Nov 2008 18:58:27 GMT, (Mark Sizzler) wrote,
    > quoted or indirectly quoted someone who said :
    >
    >> We have problems with the Java Garbage Collector.

    >
    > Finally there is the ballerina in phone booth problem.


    I hadn't heard it called that before. That's a great name!

    tom

    --
    A paranoid-schizophrenic is a guy who just found out what's going on. --
    William S. Burroughs
     
    Tom Anderson, Nov 21, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob Tillie

    Garbage Collector Debugging

    Rob Tillie, Aug 15, 2003, in forum: ASP .Net
    Replies:
    11
    Views:
    1,764
    JerryK
    Aug 18, 2003
  2. Pyramis
    Replies:
    0
    Views:
    403
    Pyramis
    Jan 25, 2004
  3. Colt

    Garbage collector problem

    Colt, Nov 15, 2003, in forum: Java
    Replies:
    9
    Views:
    688
    Tim Ward
    Nov 18, 2003
  4. bart59
    Replies:
    0
    Views:
    503
    bart59
    Jun 17, 2004
  5. Replies:
    16
    Views:
    604
    Friedrich Dominicus
    Oct 11, 2007
Loading...

Share This Page