• Post Reply Bookmark Topic Watch Topic
  • New Topic

A better garbage collector than the one used in Java ?  RSS feed

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • 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
Chrome IBM DB2 Java
  • Mark post as helpful
  • send pies
  • 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: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • 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
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • 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: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • 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.)
 
Sheriff
Posts: 22846
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • 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: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • 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
Sheriff
Posts: 22846
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • 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: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • 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
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • 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
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • 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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!