i am trying to run some code sample from my Java book, and the output is not the same as in the book: the programm ends before the gc() does it's job. i have tried both jdk1.2.2 and jdk1.3.1_01, but there is no difference (actually, there is: on jdk1.3.1_01 the programm ended even more quickly). then i've did it on another computer, and it worked just as in the book example. why?
Are you working on same OS on both computer, with same configuration? Normally, GC won't start collecting object until your memory begins to be full. One thing to know, there is an initial heap size and a maximum heap size. I'm not sure how the initial and the maximum heap size is calculated, but you can modify it this way: (Originally posted by Jessica Sant) Heap can be defined with the following params: -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size You may find somme interesting linkshere and here So, as I understand there is a corellation between your RAM and the Heap size. Hope it helped you [ June 21, 2002: Message edited by: Younes Essouabni ]
By constantly trying one ends up succeeding. Thus: the more one fails the more one has a chance to succeed.
SYstem.gc() will not cause garbage collection to be executed. You should consider it no more than a suggestion to the JVM that garbage collection might be a good idea right now if it isn't too inconvenient.
ok, but what i don't understand is why when i run this program on the first computer the garbage collector always collects all the objects, but if i do it on the second computer, it collects only part of them.
Are the two computers running different JDK versions? There have been a number of improvements (and more rarely, new bugs) in garbage collection, coming out in each new JDK release. You may also see differences because of different OS's on the computers (which may lead to different JDK's) or because the JVM's are allocated different amounts of memory. A JVM with little heap space available will usually work harder to free memory than one with a lot of heap available. (At least, this is true if you're right at the limit - not sure otherwise.) To see what's going on with GC I like to run with java -verbose:gc. This reports all GC activity. I find that often if I call System.gc() twice in a row, the second call manages to collect some things that weren't collected the first time. If I want to be really sure that it's collected everything it's going to, I call gc() three times in a row; the third time almost never adds anything new. (There's still no guarantee everything has been collected, but if you can call 20 more times in a row and see no change, that's a good clue.) Obviously this makes the JVM work harder, and usually it's not very useful, but it's good for studying memory usage and figuring out which objects are eligible for collection. As long as you're not too concerned about performance at the same time.
"I'm not back." - Bill Harding, Twister
Joined: Jan 30, 2000
OK, I reread your posts above. It seems you're comparing the same JDK across two slightly different OS's. How much RAM is available on each computer? And how much of this RAM is being used by java.exe when it runs? If one system is unable to keep the whole JVM in RAM, the JVM may work harder to collect objects, to avoid using virtual memory since it's much slower. This is just a guess, but seems plausible to me at least.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: how System.gc()'s work depends on the machine?