GCJ 3.3 LEAKS Throwable & Derived Classes

["Craig A. Vanderborgh" <craigv at voxware dot com>]

Hello:

We have just uncovered a really horrible problem with GCJ 3.3, on 
multiple platforms (x86 linux, arm-wince-pe, ARM/linux).

Instances of Throwable, and classes derived from it are leaked by 
garbage collection, in the following way.  The GC heap size is 
unaffected, but the process virtual size/RSS reflects the leakage.  Here 
is a sample program that demonstrates the problem:

class Catcher {
 public static void main(String [] args) {
   System.out.println("now in main");

   while (true) {
     Exception foo = new Exception();
   }
 }
}

The output from Boehm GC (GC_STDOUT/GC_PRINT_STATS turned on) appears 
"normal", and the heap size reported seems reasonable.  But the PROCESS 
SIZE grows without bound, until the test machine is brought to a standstill.

All you have to do to make this work is NOT allocate Throwable or a 
class derived from Throwable.

Questions:
1. Why would GC be so discriminating?  GC is being invoked in the above 
test, but it simply does not deallocate Throwable or classes derived 
from it.  It's as if GC just completely ignores these objects.

2. I have been reading boehm.cc and related code looking for anything 
that might treat Throwable specially.  I cannot find anything.  Does GCJ 
3.3 consider Throwable to be a "normal object", and should GC be able to 
deallocate it?

We are being massively killed by this problem.  Please, GCJ experts, 
throw us a bone if you possibly can.

NOTE: GCJ 4.0.2 DOES NOT exhibit this problem.  Unfortunately, GCJ 4 is 
so "embedded system unfriendly" that we are unable to use it.  So this 
issue/discussion pertains to GCJ 3.3 only.

Thanks in advance,
craig vanderborgh
voxware incorporated