gc() by Application program

[Eung maeng]

hi guru,
Does anyone answer whether application java program can use Garbage collection,gc()in process?

I am trying to release the memory regurally in processing while executing the java application.

thanks for your comments,

[Peter Chase]

It is rarely necessary or appropriate to call System.gc() and will rarely offer any performance improvement.

First, System.gc() is not guaranteed to do anything. An implementation of it might do nothing. In practice, JVMs typically do some GC when System.gc() is called, but they do not guarantee to perform a full GC.

Second, modern JVMs are generally much better than programmers at determining when would be a good time to do GC. You're almost always better off just letting the JVM choose. It can be worth tweaking the various JVM settings (-X and -XX options) for the GC; check out the documentation for the "java" command, relating to your particular JVM.

[Raghavan Muthu]

That's very true. Jesper has nicely explained.

'invoking gc() is mere a request but not a command. The request is not guaranteed to get executed as expected'.

[Balasubramanian Chandrasekaran]

Originally posted by Paul Maeng:
hi guru,
Does anyone answer whether application java program can use Garbage collection,gc()in process?

I am trying to release the memory regurally in processing while executing the java application.

thanks for your comments,

Invoking gc() is not a right process to gain resources.You can make your object references to be null after its usage which makes it available for Garbage Collection.Thats the best you can do.

[Peter Chase]

Originally posted by Balasubramanian Chandrasekaran:
You can make your object references to be null after its usage which makes it available for Garbage Collection.Thats the best you can do.

Setting local variables to null, in a method, is rarely worthwhile. When I see code that does it a lot, I take it as an indication that the programmer was inexperienced. Perhaps (s)he had just learnt about garbage collection, but not the best programming practices.

Generally, if you abide by the principle of declaring your local variables in the smallest scope that makes sense, you will not need to set any of them to null, because they'll go out of scope plenty soon enough.

Setting object fields to null is more often likely to be worthwhile. However, there is again a general principle that unmodifiable (final) fields are better than modifiable fields. If you abide by this, and instead ensure the whole object doesn't have a longer lifetime than necessary, you'll rarely find it necessary to null-out fields either.

[Raghavan Muthu]

That's very perfect Peter.

Thank you again for helping me reiterate the stuff

[William Brogden]

I know of one case in which it is reasonable for your application to call gc() - just after the program has filled the user's screen with information which you know will take some time to read and decide on the next step.

Any delay at that point will not be noticable, and presumably you have released all the temporary objects that were needed to create the data.

Bill

[Eung maeng]

I really appreciate all comments.
That's why I like to visit this site..

[Debabrat Nayak]

Paul,
Garbage collection is a lower priority activity for the JVM. Hence, even if you invoke System.gc(), it doesn't guarantee garbage collection instantly. You can configure JVM parameters to do more efficient garbage collection. Please note that too frequent GC is also not good as it will result in higher resource usage (like CPU) and can inversely affect the performance.

[Peter Chase]

Originally posted by William Brogden:
I know of one case in which it is reasonable for your application to call gc() - just after the program has filled the user's screen with information which you know will take some time to read and decide on the next step.

Any delay at that point will not be noticable, and presumably you have released all the temporary objects that were needed to create the data.

I see what you're getting at, but I don't think it's a good idea, in most cases.

Remember that GC is a system-wide activity that affects all threads. Although the GUI may have reached an idle time, can you be sure that other threads aren't doing something important? And, even if you can be sure now, can you be sure that it will remain true in the future? Especially if someone borrows some of your code for another project.

[William Brogden]

Remember that GC is a system-wide activity that affects all threads. Although the GUI may have reached an idle time, can you be sure that other threads aren't doing something important?

Then the JVM should take care of the problem by not actually starting a gc thread - recall that gc() is a suggestion not a command.

NOTE: I am not talking about a multiple-client server situation here where you have no ability to know what the rest of the JVM is doing.

Bill

[Ilja Preuss]

Originally posted by William Brogden:

Then the JVM should take care of the problem by not actually starting a gc thread.

But shouldn't the same be true the other way around - shouldn't it notice when there is idle time and start a gc cycle then, without me needing to explicitely call anything?

[William Brogden]

shouldn't it notice when there is idle time and start a gc cycle

The JVM may recognize idle time but it may look at available free memory and decide there is no reason to run gc. My feeling is that for some applications, the architect of the program knows best.

Bill

[Billy Tsai]

assume we have the following methods
there might be a number of exporters in a collection and each exporter is looped through and passed into the following exportData method

public void exportData(Exporter exporter){
Object[] data = DAO.getUnprocessedData();
//assume there are 20000 objects retrieved everytime
for(int i=0; i<data.size; i++){
exporter.exportData(data[i]);//this method will additionally load
//lots of objects into memory
data[i].setProcessed(true);
}
updateDataStatus(data);
//whats the effect of declaring data = null; here?
//whats the effect of declaring exporter as null here?
}

private void updataDataStatus(Object[] data){
Object[] tempData = data;
// there will be two copies of an object array containg 20000 objects
// in the memory at this time?
// which might cause an OutOfMemoryError
StatusDAO statusDAO = new StatusDAO();
for(int i=0; i<tempData.size; i++){
statusDAO.update(tempData[i]);
//whats the effect of declaring tempData[i] = null;
}
//whats the effect of declaring data = null; here?
//whats the effect of declaring tempData = null; here?
}


whats a good way to prevent memory leak from occurring in these methods
[ January 21, 2008: Message edited by: Billy Tsai ]

[Peter Chase]

I don't know why you have appended your question to this old thread. It should be in a new thread, please. I'm closing this thread.