Garbage Collection Help!

[Prateek Rawal]

Hello everybody,

I was studying GC recently. Although i understood most of the things, i have doubt in the following code:

import java.util.Date;
public class Test{

public static void main(String[] args){

Runtime rt = Runtime.getRuntime();

System.out.println("Total JVM Memomry: "+rt.totalMemory());

System.out.println("Total free Memomry before GC: "+rt.freeMemory());

Date date = null;
for(int i=0;i<10000;i++)
{
date = new Date();
date = null;
}

System.out.println("Total free Memomry before GC after creating objects: "+rt.freeMemory());

rt.gc();

System.out.println("Total free Memomry after GC after creating objects: "+rt.freeMemory());

System.out.println("Total JVM Memomry: "+rt.totalMemory());
}
}

I understood the code, but the problem is i get the same output everytime i run the program. Even though i close the instance of command prompt and start a new one and run the program, the same output is generated as follows:


Total JVM Memory : 5177344
Total free Memory before GC: 4982640
Total free Memory before GC after creating objects: 4734752
Total free Memory after GC after creating objects: 5048344
Total JVM Memory : 5177344


Just tell me what should i conclude from it?

[Deepak Bala]

Nothing.

The call to gc() is not always guaranteed. All you can infer is that total memory at point X is A and free memory at point Y is B. It is more important that you understand the number of objects that can be GCed at any point in time

[Prateek Rawal]

From the output it is clear that

The free memory(after the objects have been created) and before GC ran is less than the free memory after GC ran(and also possess exact values), thus some memory is being freed. Thus it is sure that gc() is running everytime.....

What say?

[Prateek Rawal]

Just give me some reply guys,

i have been waiting for an answer, atleast the moderators should help me out,

i'm trying to understand something here and thats what JAVARANCH is all about, asking queries and getting help, don't anyone bother to help me out.

I see other posts getting 5-6 replys within a day and i got a single one.

What is this?

Atleast tell me if at all this is an absurd question or whatever.....

[Abimaran Kugathasan]

Prateek Rawal wrote:
Thus it is sure that gc() is running everytime.....

Can't tell it surely.

BTW, Please be patient! Your question sees to be some what 'big', that's why no responses! Check the no view of this Thread at the bottom!

[Vinayagar Karpagam]

In theory, the free memory can go down after a GC; a very common example being the presence of another thread that creates Objects in parallel with the thread that invoked the GC. In my opinion there is no final answer to the question. Only thing that can be said is that you cant conclude that GC ran and freed memory by just checking that the free memory goes up after GC.

[Abimaran Kugathasan]

Vinayagar Karpagam wrote:In theory, the free memory can go down after a GC; a very common example being the presence of another thread that creates Objects in parallel with the thread that invoked the GC. In my opinion there is no final answer to the question. Only thing that can be said is that you cant conclude that GC ran and freed memory by just checking that the free memory goes up after GC.

Seems, you've accessed this forum after long time!

[Vinayagar Karpagam]

Yes, even though it is not related to the current thread I've been staying as a watcher for quite some time. Just started posting replies.

[Henry Wong]

Prateek Rawal wrote:From the output it is clear that

The free memory(after the objects have been created) and before GC ran is less than the free memory after GC ran(and also possess exact values), thus some memory is being freed. Thus it is sure that gc() is running everytime.....

What say?

I don't know why people always conclude that because the gc() method is not guaranteed, that it means that you can run it many times, and randomly there will be times where it won't run.

The reason that it is not guaranteed, is because there are cases where it can't run, and the code just doesn't decide arbitrary to not run. It will try it best to perform the gc() on request. It may not run because there is already a gc in progress (obviously, the parallel new gen gc). Or it may not run because you configured it (via a -XX switch) to not run.


In this example, there isn't enough allocation to trigger a gc (running out of new heap), nor is the -XX flag set, so the gc should be honored every time.

Henry

[Himanshu Mall]

@Prateek

Yes, you should not conclude anything about GC and you MUST NOT SPECULATE about it either.

Ref java.lang.Runtime.

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

Moreover to make sure that GC ran is to see whether GC ran or not.

use -verbosegc flag while running the program.

java -verbosegc <Main-Class>

Let us know what you see when you do it.

[Prateek Rawal]

after using -verbosegc option i got the following output:



Total JVM Memory : 5177344
Total free Memory before GC: 4982640
Total free Memory before GC after creating objects: 4734752
[Full GC 432K->107K(5056K), 0.0103799 secs]
Total free Memory after GC after creating objects: 5048344
Total JVM Memory : 5177344

Every time i run it, i get all the values same except the time in seconds,it varies.

What should i conclude?

See, let me very frank! I'm not a pro in Java, so i don't understand the stuffs Henry said above:

The reason that it is not guaranteed, is because there are cases where it can't run, and the code just doesn't decide arbitrary to not run. It will try it best to perform the gc() on request. It may not run because there is already a gc in progress (obviously, the parallel new gen gc). Or it may not run because you configured it (via a -XX switch) to not run.


In this example, there isn't enough allocation to trigger a gc (running out of new heap), nor is the -XX flag set, so the gc should be honored every time.

My question is as plain as anything:

Since the free memory after gc() is invoked increased, can we conclude that Garbade Collection happenned? and if not, what reason would you give of the increase in free memory?

and one more thing after the memory is freed, when we run the program next time, why the following values is same as before:

Total JVM memory
Total free memory before GC(even though last time the free memory increased,and when again we run,it comes down to the same value,why so?)

PS: Please explain in simple language, without using too much high fundoo words, remember i'm a scjp aspirant and not a java pro

[Rodmar Conde]

when we run the program next time, why the following values is same as before

I'm not an expert too, but I know that each time you run a class, the jvm allocates a new piece of memory for it to run (called heap). You can modify its size with the following parameters:

-Xms<size>
-Xmx<size>

Please try java -Xms100m -Xmx105m Test and you should get a different value in "Total JVM Memory".

[Prateek Rawal]

Thanks Rodmar, that was indeed a help.....

Yeah,you were right, i got new value as Total JVM Memory....

But what about this:

Total free memory before GC(even though last time the free memory increased,and when again we run,it comes down to the same value,why so?)

Any idea on that one?

[Henry Wong]

Prateek Rawal wrote:
Since the free memory after gc() is invoked increased, can we conclude that Garbade Collection happenned? and if not, what reason would you give of the increase in free memory?

Yes, you can conclude a gc happened due to the drop in used memory. You can't conclude that it is due to your gc() method call -- as it is possible for an actual gc cycle to occur on its own, between your print out requests.

And as mentioned, you can disable the gc() method with the -XX flag.... specifically, the...

-XX:+DisableExplicitGC

Try adding it to your command line. You will see that your System.gc() method calls won't do anything anymore.

Henry

[Prateek Rawal]

Okay,after i disable Eeplicit GC, i'm getting the same free memory value before and after gc() was invoked....

that means till now, it was the in-built pheneomenon of Garbage Collection that was happenning and not due to my calling gc() method.....

And strangely it was happenning exactly everytime between those prints out statements....strange,isn't it....any reason for that?

And one more thing:

After i run the program 1st time(by doing disableExplicit GC), i get the following output:


Total JVM Memory : 5177344
Total free Memory before GC: 4982672
Total free Memory before GC after creating objects: 4734696
Total free Memory after GC after creating objects: 4734696
Total JVM Memory : 5177344

Then again i run the program(by doing disableExplicit GC),i get exactly the same output as above.....

Whatever free memory was left at the end of 1st run has no relation with the second run....is it?

And as someone pointed out earlier that "everytime you run a class JVM is allocated a piece of memory(i guess based on some default values)".....so it is thus reasonalbe that Total JVM Memory remains same but what about Total free memory before GC?

Does it mean that Whatever free memory was left at the end of 1st run has no relation with the second run....is it?
and is it happening that every time we run the program a fixed number of objects are created(thus a fixed memory is used) thus the free memory comes out to be same,is it the case?

[Vinayagar Karpagam]

Prateek,

There will be no impact of 1st run in the free memory during second run, simply because they are two different processes.

and is it happening that every time we run the program a fixed number of objects are created(thus a fixed memory is used) thus the free memory comes out to be same,is it the case?

Probably, yes.

Henry,

Can we consider the thread priority as a reason for gc() call to be ignored? In other words, since the garbage collection is supposed to run under a lower priority, can a gc() request get ignored due to a higher priority thread being active? Is there a documentation that covers the priority of the GC threads? Because typically in most of the heavy applications, the application runs out of free memory and has actively running higher priority threads. Won't that impact the GC from freeing the memory which is counter-productive?