Java Reference
In-Depth Information
Let's examine these results a bit. First, we can see that the young generation has 17920K allocated
and is using 8077K of it. All of the objects in the young generation are in the eden space. Given how
briefly instances of the
Target
class last, there should never be one in the from and to spaces. In the
tenured generation (called PSOldGen here), we find nothing, although 40960K has been allocated to it.
The instances of the
TargetClick
and
TargetClickPanel
class are not in the tenured generation because I
took this snapshot shortly after starting the TargetClick game, so those objects are still in the eden space.
Finally, the permanent generation contains the three class files, which use 9423K of 21248K allocated.
To really make this information useful, we'd have to let the program run for a while, find a number
of these blocks of information, and compare them to one another, watching for changes over time. As
you can imagine, analyzing this kind of information for a large and complex program can take quite a
while. For one thing, developers working on those kinds of applications often have to let their
applications run for days at a time to get a sufficiently broad window of input. Also, if the number of
users or number of network connections or other load factors change (and they nearly always do - very
few programs exist in constantly stable environments), those factors need to be captured and then
identified in the log. Then there's the difficulty of reading this kind of information (which is why many
programmers write additional utilities to “scrape” this data and put it into some handy application, such
as a spread sheet). All of this together makes analyzing garbage-collection data a non-trivial task.
However, the task pays off with better performance, happier users, happier programmers, and so on.
Therefore, the investment in time and effort often pays off nicely.
■
Tip
You can get a good optimization by monitoring the size of the tenured generation over the lifetime of your
program and setting its size to closely match (with perhaps a 10% increase) the tenured generation size to the
largest size you observe over a few runs of your program. You can control the size of the tenured generation by
controlling the size of the new generation, which you can do with the
-XXNewRatio
,
-XX:NewSize
,
-
XX:MaxNewSize
switches. Suppose your testing reveals that your program needs 256MB of memory and that the
tenured generation should be 4 times the size of the new generation (meaning you have a lot of long-lived
objects). You could set the following switches:
-XXNewRatio=4 -XXNewSize=52MB -XXMaxNewSize=52MB
Collection Hints
Java developers can give hints to the garbage collector. The following line asks the JVM to do garbage
collection for your program:
Listing 13-4. Garbage Collection Hint
System.gc();
However, most of the Java programming community frowns on using garbage collection hints.
Instead, you should try to organize your code so that the garbage collector doesn't need a hint. Most of
that organization comes down to arranging your classes such that each class has a clear, well-defined job
to do. For example,
TargetClickPanel
maintains a collection of five
Target
objects. When it needs a new
instance of the
Target
class, it sets a member of that collection to the new instance. Thus, old instances
become free for collection. If I had tried to do more with that collection of
Target
objects, I might easily
