R. Vince wrote On 06/07/07 09:42,:

   The usual wisdom is that the JVM has a more accurate
idea of the state of memory than you do.  Its decisions
about when to collect garbage, since they are made in
light of the actual run-time memory pressure, are likely
to be better than static decisions you make at coding
time without benefit of the JVM's knowledge.

   In very rare cases you might do better than the JVM,
because the knowledge advantage is not entirely one-sided.
The JVM has better information than you do on the current
state and recent history of memory, but has no knowledge
of the program's future behavior.  You may be able to
exploit your foreknowledge to choose a better moment for
GC than the JVM would if left to its own devices.

   ... but such cases are likely to be extremely rare.
About the only scenario I can come up with is a program
that runs in "waves:" it creates a huge population of
objects, then throws nearly all of them away, and then
repeats.  You might get some advantage by running GC in
the "troughs," just after the great object die-off and
before the ensuing population boom.  But that's "might"
as in "it's conceivable, I suppose," and not a promise of
any benefit -- it's not even a promise of no harm!

   Suggestion: Gather some statistics on the actual GC
behavior of your program.  If you find that GC is a problem,
your next step should be to find out why it runs so often
and so hard: Are you creating and discarding objects sub-
optimally, as in

    String s = "";
    for (String s2 : hugeCollectionOfStrings)
       s += s2;

Reducing "object churn" will probably do more to help with
GC than quite a lot of GC-centered fiddling.  (Memory
profilers may also be of help here.)

   If GC is still a problem even after you've done all you
can to use your objects intelligently, then and only then
should you resort to fiddling with the GC itself.  And if
you do, be sure to measure what happens and compare with
the original, pre-fiddling measurements: "tuning" GC may
actually have made things worse, and it may be necessary to
"de-tune" it just to recover the status quo ante.

Probably. But you can never 'force' the JVM to do garbage collection.
System.gc() will only 'suggest' that now may be a good time to do GC
(but under certain circumstances, I think it has to do with system
load, the JVM might simply ignore the call). Anyway, I think the cost
for calling System.gc() is not huge, so perhaps I think it might be
worth a try.

I for myself remember having used System.gc() exactly once so far - in
one project I was running >200 Unit Tests, and every test case was
creating an in-memory representation of a WSDL file and compiled XML
Schemata using XMLBeans. At some point in the test run the JVM just
stopped with OutOfMemory. Putting a System.gc() at the end of every
single test case solved the problem just nice.

/philipp

It is most likely that the JVM is much better than your code
to determine what is optimal times to GC and that explicit
calls to System.gc will decrease performance.

Have you tried experimenting with the -X and -XX JVM parameters
that controls GC ?

Arne

Try it.  It might ignore you anyway. At worst it will go slower, and
you take them out.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

One scenario where you might get a better responsiveness
is calling gc() when a Java GUI application is minimized (or loses focus).

If you don't, imagine the OS swapping the memory out and when you switch
back to the application
one of the first things that happens is the JVM decides it needs to
do a gc run - a lot of that heap must first be swapped back in.