[GC PIC] Appendix C.   Digging Through Your Garbage


[ This appendix does not appear in the book. ]

Popular criticisms of the JVM include that it's prone to 'memory leaks', and that it performs frequent and lengthy garbage collections at unpredictable times. The collection pauses are especially painful for games which should guarantee fast responsiveness at all times. Since Java doesn't offer a version of C's free() or C++'s delete(), then the programmer has no way to control or guide the JVM's feeble-minded garbage collector.

The main aim of this appendix is to show that the preceding paragraph is mostly rubbish (or, more aptly, garbage):

It's worth mentioning that the poor performance of a Java application isn't necessarily the fault of the JVM. Many games use external resources, such as OpenGL or DirectX, databases, and the Internet, which are beyond Java's control. There may be problems with the underlying operating environment, such as low memory, a slow CPU, or a poorly configured network.


An Outline of this Appendix

I'll start by considering memory leaks: what they are, how to find them in code, and how to get rid of them.

I'll supply background information on the generational approach to garbage collection used in the JVM, information I'll need in order to decide how to tweak the collectors.

I'll describe several techniques for reducing collector pause time, by experimenting with two examples: JumpingJack (the side-scroller from chapter 12) and FPShooter3D (the first-person shooter from chapter 24). The basic approach is to supply options to the JVM; no changes are needed to the application code.

I'll graphically display the copious amounts of performance information generated by the JVM. Garbage collections statistics will be visualized with HPjtune, and profiling details rendered with HPjmeter. Both are freeware tools that work with a wide range of JVMs.

I'll finish by describing techniques for gathering heap-related statistics by adding code to Java applications.

An underlying assumption of this appendix is that the programmer will be using J2SE 1.4.2 or 5.0. There have been many changes to the JVM over the years, and some of the techniques I'll be discussing don't work in earlier JVMs.




Dr. Andrew Davison
E-mail: ad@fivedots.coe.psu.ac.th
Back to my home page