RE: arm-wince-pe-gcj: Finalizers not getting called

["Boehm, Hans" <hans_boehm at hp dot com>]

I agree with Tom, but I would recommend getting this to work correctly before
switching to hash synchronization.  The hash synchronization code uses finalization
in a much more subtle way.  It would leak less if finalization were completely broken,
but it would still leak.  And it would be far harder to debug.

You might also want to look at what happens to GC_fo_entries as your application
is running.  This is the number of objects the GC thinks will eventually need finalization,
but aren't yet ready to be finalized.  Once the GC thinks they're ready to be finalized,
they're moved to the GC_finalize_now list.  If the GC thinks objects remain reachable,
GC_fo_entries should keep growing.  If that's not the case, check that GC_invoke_finalizers
is getting called.

I'm somewhat surprised that every allocation results in a CriticalSection object.
That should only happen if the lock associated with the object is used.  Is that
plausible for your application?  (If it is, hash synchronization may be a large win.)

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Tuesday, July 29, 2003 10:31 AM
> To: Craig A. Vanderborgh
> Cc: java@gcc.gnu.org
> Subject: Re: arm-wince-pe-gcj: Finalizers not getting called
> 
> 
> >>>>> "Craig" == Craig A Vanderborgh <craigv@voxware.com> writes:
> 
> Craig> 1. The configuration is done so that the finalizer, 
> finalize_sync_info()
> Craig> is there as it should be.
> Craig> 2. finalize_sync_info() contains the needed DCS
> Craig> 3. The finalizer is apparently "registered" via the 
> RegisterFinalizer
> Craig> call.
> 
> Note also that you're using non-hash synchronization.  This is slower
> and needs more memory (an extra pointer per object).  You might want
> to consider porting the hash sync code to ARM.
> 
> Tom
>