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):

• Memory leaks can be easily detected and fixed. Memory leaks aren't the fault of the run time system, but a symptom of bad programming style.
   
• The JVM supports a vast range of garbage collection capabilities (including six different collectors).
   
• It's straightforward to adjust the JVM's behaviour to change the length and frequency of garbage collections. For example, it can be configured to perform numerous short collections, or fewer longer-duration collections.
   
• Although Java doesn't offer free() or delete(), there are programming techniques which can encourage and help garbage collection. However, most 'tweaking' of the collection strategies is done via command line options to the JVM.

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.

Downloads

• The PDF file for the Appendix C (555 KB).
  Last updated: 23rd November 2005.
   
• Zipped Examples from Appendix C (4 KB).
  Last updated: 23rd November 2005.

• Up to the Killer Game Programming in Java Index Page
• Back to Appendix B. Installation using Java Web Start

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