FAQ-0766 My Java app crashes unexpectedly following garbage collection. What might be causing this?


FAQ-0766 My Java app crashes unexpectedly following garbage collection. What might be causing this?

» Symbian OS » Developer Knowledgebase » FAQ-0766

Classification:	Java	Category:	AWT
Created:	01/21/2002	Modified:	02/19/2002
Number:	FAQ-0766
Platform:	ER5, Symbian OS v6.0, Symbian OS v6.1

Question:
My Java app crashes unexpectedly following garbage collection, with a KERN-EXEC 3 error reported in the AWT-Server process. What might be causing this and is there anything I can do about it?

Answer:
This problem stems from a limitation of Symbian's AWT Java implementation, whereby native objects representing Java AWT objects contain pointers to otherJava objects. In exceptional circumstances the Java objects may be moved by the garbage collection mechanism and the pointers in the native objects not updated. The way this problem manifests in practice depends on whether a new Java obect is assigned to the memory location to which the dangling pointer continues to point, and what kind of object that turns out to be. Usually, however, the result will be a KERN-EXEC 3 error reported in the AWT-Server process, with consequent application crash.

This problem has been found to arise in two distinct circumstances.

1. When the Java virtual machine runs out of heap space, an attempt will be made to compact the heap.
2. When an explicit call is made to System.gc() from user code which is manipulating AWT objects (such as a setVisible() method).
The first of these can be avoided by setting the initial heap space sufficiently large that the limit is never reached in practice. This can be accomplished by passing a value through the -ms flag (in the associated .txt file) to the VM at app launch. For example including "-ms1000k" will launch the VM with an initial heap space of 1 MB. Some good advice here to help prevent excessive expansion of the heap is to avoid the creation in rapid succession of an excessive number of AWT objects, which can be expensive in heap usage in the short term. Given time, de-referenced objects will be successfully reclaimed by the garbage collector but, in the light of (2), avoid explicitly launching the garbage collector to this end. Where possible, re-use of existing objects is of course the best course.

The way to avoid the second case is self-evident: avoid making calls to System.gc() in parts of your code which are manipulating AWT objects. In fact, the safest course is probably not to make any calls to System.gc() at all.