System.gc() improves the performance?

[Ahmed Moustafa]

On Linux 2.4.20-19.7 and JRE 1.4.2, there is code that takes on the
average 20 milliseconds but if System.gc() is called just before, the
same code will take on the average 3 milliseconds.

Does that make any sense?
Is it *really* necessary to call System.gc()?
Is this scenario system dependent?

Thanks in advance!

 

[Roedy Green]

On Linux 2.4.20-19.7 and JRE 1.4.2, there is code that takes on the
average 20 milliseconds but if System.gc() is called just before, the
same code will take on the average 3 milliseconds.

System.gc is very efficient if you call it when there are very few
objects, because it works by finding all live objects. It does not
matter how many dead ones there are.

There are natural breaks in an application where you have just deleted
masses of objects and are just about to create a bunch more. That is
the ideal time to insert a System.gc.

for more details see http://mindprod.com/jgloss/garbagecollection.html

 

[Ahmed Moustafa]

On Linux 2.4.20-19.7 and JRE 1.4.2, there is code that takes on the

System.gc is very efficient if you call it when there are very few
objects, because it works by finding all live objects. It does not
matter how many dead ones there are.

There are natural breaks in an application where you have just deleted
masses of objects and are just about to create a bunch more. That is
the ideal time to insert a System.gc.

for more details see http://mindprod.com/jgloss/garbagecollection.html

Is it possible to hold the Garbage Collector from doing anything
starting from a point in the application till another point?

 

[Adam Maass]

Is it possible to hold the Garbage Collector from doing anything
starting from a point in the application till another point?

No, but judicious use of System.gc() and tuning parameters might give you a
high degree of confidence that the GC will be inactive for some period of
time.

-- Adam Maass

 

[Roedy Green]

Is it possible to hold the Garbage Collector from doing anything
starting from a point in the application till another point?

not really. It runs when it runs out of ram. It can't very well
postpone doing something about that.

A generational collector presumably could be temporarily turned off,
but I know of no way to do that.

 

[Roedy Green]

Is "running out of memory" the only trigger to the garbage collector?

The rules are deliberately vague to give maximum flexibility to the gc
implementation. I'm not even sure if there has to be a gc at all for
a JVM to qualify as Java. I suppose in theory, it could just keep
allocating more virtual RAM.

gc tends to run when you call system.gc. It obviously HAS to run if
you run out of RAM. It might tend to run if the system is idle.

Some gcs run all the time on another processor.

 

[Steve Claflin]

The rules are deliberately vague to give maximum flexibility to the gc
implementation. I'm not even sure if there has to be a gc at all for
a JVM to qualify as Java. I suppose in theory, it could just keep
allocating more virtual RAM.

gc tends to run when you call system.gc. It obviously HAS to run if
you run out of RAM. It might tend to run if the system is idle.

Some gcs run all the time on another processor.

I've always wondered if you can push the JVM toward garbage collection
by calling sleep() for all your threads.

Also, I did once construct a situation where I generated and printed a
long list of objects whose finalize method also printed a message; on
some implementations that bogged down the whole process to the point
that it hung (it more or less ran along the lines of create 1000, remove
500, repeat). Granted, I kind of forced the issue by putting slow stuff
in finalize, but it seems like a real-world application might run into
that problem for its own reasons.