Re: Garbage collection
Mike Schilling wrote:
Eric Sosman wrote:
Mike Schilling wrote:
Eric Sosman wrote:
The prevailing wisdom is that System.gc() is very seldom a
good idea, particularly in code that is expected to run on a
variety of different JVM implementations with different garbage
collectors. In limited circumstances when the code is running on
one well-researched version of one specific JVM it may make sense,
but that's about it. Calling System.gc() is, in essence, making
a static decision based on predicted conditions instead of letting
the JVM make a dynamic decision based on actual conditions. You
may be smarter than the JVM, but the JVM has much more information
than you do.
As always, there are exceptions. Say you have a program that:
1. Interacts with the user
2. When asked to, runs some time and memory-intensive processing
3. Interacts with the user some more
It makes sense to call System.gc() at the end of step 2, so that
the
time required for the GC doesn't interrupt the user interaction.
Note that I wrote "very seldom," not "never."
You, I think, should have written "may make sense" instead
of "makes sense." The fact that Step 2 is time-intensive is
irrelevant,
Not at all. If the user is already expecting to wait for the
processing to complete, the added wait for GC becomes invisible, which
is the point.
and the fact that it is memory-intensive matters
only if (1) a lot of garbage has accumulated and (2) a collection
is imminent anyhow.
The point is that, the wait at the end of 2 being invisible to the
user, it's worth doint to avoid a visible wait later. An insurance
premium, if you like.
An insurance premium where the insurance company makes no promise to pay off a
claim. If memory was getting tight, the JVM likely already scheduled the GC
before you called gc(), and if it wasn't, it'll perhaps ignore the request.
and anyway, what's the big deal if memory isn't tight? If the JVM doesn't
ignore the gc() request, you just invoked a GC where there would have been
*no* delay otherwise, because there would've been no collection.
There are many ways to tune GC to avoid excessive pauses. Calling gc() really
isn't one of them.
The simplest is to exploit Java's memory style idiomatically - keep the
lifetime of objects very short so that they get collected from the young
generation. If you never incur a full GC, you probably will never see long
pauses.
Note that the size and number of the objects don't matter. Dead objects don't
incur overhead in young-generation collections, so you can allocate a shipload
of massive objects as long as you dereference them quickly.
Beyond that, how many dozen GC-related parameters are there for the JVM?
<http://blogs.sun.com/watt/resource/jvm-options-list.html>
I counted four dozen before I decided that made the point. And that's just
for Sun.
--
Lew