• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

A better garbage collector than the one used in Java ?

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have some questions about the Java garabage collector -
1- Is it "perfect" or has someone made something better ?
2- Is it improved every once in a while ?
3- How much should one rely on GC ?

 
Ranch Hand
Posts: 859
IBM DB2 Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1 - No.
2 - Yes. Look at the release notes for jvm improvements.
3 - Don't fret too much it. It runs away and does it's job. Look out for your own memory leaks.

WP
 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Objection! Compound question! Oh, sorry... I'm a lawyer, and objecting is fun. "Is it perfect?" No. Only God and my mother are perfect. Has someone made something better? Would it surprise you if I said, "That depends on what you are doing"? Regardless, I bet you will find it is good enough that looking for something better isn't worth your time.

2. Yup. Again, you may not find it's worth worrying about, but you read about improvements from time to time.

3. Maybe as much as you rely on your CPU or your favorite compiler: until it breaks down or a bug appears, it is reliable enough that you can be sure that worrying about other things is a better use of your time.

FWIW (3d edition) I found myself mildly obsessed with the GC when I first learned of its existence. I have since observed that such obsession is common for new Java programmers. You get over it pretty quickly when you realize that (*gasp!*) there are no pointers to memory in Java. Without them, the kind of thing that makes one-time C programmers (like me) find reliance on the GC so hard to come by just isn't a consideration. That is, the sort of thing that makes the GC a source of such anxiety for newcomers to Java just doesn't come up, because the Java language doesn't permit it. Getting used to programming without pointers is another story. But that's where your time should go. Forget about the GC for now. If you know it exists, that it reclaims memory from data structures (that is, "objects") after they are no longer used, and that it has held up in the field extremely well, you know what you need to know to be doing more useful things.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:1. Objection! Compound question! Oh, sorry... I'm a lawyer, and objecting is fun. "Is it perfect?" No. Only God and my mother are perfect. Has someone made something better? Would it surprise you if I said, "That depends on what you are doing"? Regardless, I bet you will find it is good enough that looking for something better isn't worth your time.



Well, the new Oracle JVM's GC is supposed to be much better. Also, you can get a JVM with an incremental GC from IBM or BEA (the later option is also owned by Oracle). And of course, you have the Azul pauseless GC, which is the only JVM with a GC that is both concurrent and parallel -- this JVM can get up to ridiculous heap sizes because of it.

Henry
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:you can get a JVM with an incremental GC from IBM or BEA (the later option is also owned by Oracle). And of course, you have the Azul pauseless GC, which is the only JVM with a GC that is both concurrent and parallel -- this JVM can get up to ridiculous heap sizes because of it.



I think that's the kind of thing that makes new Java programmers twitchy about the GC. You don't know how much heap you're going to need, and you don't know when the GC is going to run (so you don't know when it's going to be competing with your own code for CPU cycles). If you're writing a real-time app, I guess that matters. One thing I didn't know until after I was into Java for a while was that, if your application needs memory and the heap is used up, the GC will run before it lets your app fail. So, you can't ever bomb out just because the GC was late in getting your memory back for you. Before I knew that, I spent some wasted time finding out that you can't force the GC to run. You can ask, but that's all. For a C programmer, that's not very satisfying. In C, you know when you get a block from the heap, and you know when the heap gets it back. (What you don't know, and many C programmers may not even know they don't know, is what, if anything, your run-time memory manager does about fragmentation. You may allocate a zillion ten-byte blocks, then release every other one, then ask for one half-zillion-byte block. Will you get it? Maybe, but only if your memory manager can do something about consolidating all those released blocks and do something about making them occupy a contiguous range of virtual addresses, which, when you think about it long enough, starts to look a lot like what a managed language does in the first place, so what are you really getting by not using one?)

I have only ever worked on a genuine, real-time system once. The solution to all of this was to allocate absolutely everything we needed, or might need, at startup time. The rule in that shop was, "Thou shalt not allocate new memory after init() returns." I knew enough about our C compiler and our OS at that time to be sure that meant we were not subject to unpredictable blockers like long runs of some autonomous GC-like process. I don't know enough about Java or the JVM to say the same thing, but I wouldn't be surprised if that were good enough for most real-time applications. (Especially since I did my work in 1988 on '286 systems with 10 MHz clocks and 512Kb of ram. Things that would have taken too long on that hardware run somewhat faster today.)
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

David Jason wrote:3- How much should one rely on GC ?



Totally and completely. Do not try to write your own competing memory-management system in Java.
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:Do not try to write your own competing memory-management system in Java.


Hard to see how one could even do it, really. When you make an object's memory eligible for collection, with something like this:
You are precluded from further access to ob. You can't guarantee that ob's memory will be collected with this trick, only that its memory is eligible for collection. Once you've done this, however, I can't think of anything else you could do from Java itself.
 
Paul Clapham
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, that's true. But if you were writing a "We don't need no stinking garbage collection" framework, you wouldn't allow people to write that code. You would have all objects being created by factory classes which kept track of them in some way.

Now admittedly this would be hard. Very hard. The restrictions you'd have to put in place would be very severe and would make it very hard to write usable programs. But I'm sure that there exist people who would be tempted to write such a framework, and as I've already suggested, such people aren't all that interested in writing usable programs in the first place. But it's possible that it could be made to work and even be capable of producing something functional.
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Paul: Good points, all. What's the conventional wisdom on Java for real-time stuff? Allocate everything at once, as we used to do, or is something better around these days?
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:Yes, that's true. But if you were writing a "We don't need no stinking garbage collection" framework, you wouldn't allow people to write that code. You would have all objects being created by factory classes which kept track of them in some way.

Now admittedly this would be hard. Very hard. The restrictions you'd have to put in place would be very severe and would make it very hard to write usable programs. But I'm sure that there exist people who would be tempted to write such a framework, and as I've already suggested, such people aren't all that interested in writing usable programs in the first place. But it's possible that it could be made to work and even be capable of producing something functional.



This is actually somewhat common when high performance is needed. So far, I ran into more than a handful of such frameworks -- frameworks that maintain mutable objects -- objects that can hold many types of values, and track those values and whether they are even valid or not. This systems are limited to using only "objects" in this application made "heap".

The restriction on these systems are also incredibly harsh. Obviously, calculations with objects such as String, Integer, etc. are not allowed. And much of the core java lib is also restricted. In one case, the "language" isn't really Java -- just the engine is Java. This engine runs code written in some internal xml based language.

Henry
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:@Paul: Good points, all. What's the conventional wisdom on Java for real-time stuff? Allocate everything at once, as we used to do, or is something better around these days?



Interestingly, we aren't even discussing the real-time JVM -- or at least, I ain't, For example, the Azul JVM, with its pauseless GC is *not* a real time JVM. To be a real-time JVM, it would have to support the JSR 1 (and features such as immortal and scoped memory) specification.

Henry
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic