Dr Wes Munsil wrote:
> MAIN THREAD
> #4 0xee99acc8 in condvarWait ()
> #5 0xee998cc0 in sysMonitorWait ()
> #6 0xee96638c in runFinalization0 ()
> #7 0xee968d44 in manageAllocFailure ()
> #8 0xee96749c in realObjAlloc ()
Looks here like the heap is exhausted, so the VM tries to run finalizers
immediately. That's a little unusual for async GC. Either there aren't
enough idle cycles for GC to run, or the initial heap is too small.
> GARBAGE COLLECTION THREAD
> #5 0xef2d67d4 in _pthread_mutex_lock ()
> #6 0xee998a6c in sysMonitorEnter ()
> #7 0xee985080 in monitorEnter ()
> #8 0xee97960c in jni_MonitorEnter ()
> #9 0xeea4679c in Java_tcl_lang_CObject_decrRefCount ()
> #10 0xee99c504 in desc_loop ()
> #11 0xee95f7b0 in invokeJNINativeMethod ()
> #12 0xee99cdd8 in notJavaInvocation ()
> #13 0xee9711ec in do_execute_java_method_vararg ()
> #14 0xee970b9c in do_execute_java_method ()
> #15 0xee966b68 in finalizer_loop ()
Here it looks like the GC thread is trying to run finalizers too.
I worry a bit about the monitors... what finalizers are running, and
what do they do? Any use of synchronization inside finalizers is
usually a bad idea, and did cause deadlocks in 1.1.x (I heard Sun fixed
this in 1.2.x though).
Finalizers are best avoided if at all possible. They have caused more
problems than perhaps any other feature of Java.
Jeff
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
