Re heap exhaustion: either or both may be true, although the code is
incorrect if it deadlocks under those conditions. While increasing the
initial heap allocation may certainly be desirable, I am afraid that it
would not fix the incorrect code, but only make its effects felt less often.
Re finalize methods: our code contains none. There are of course some in the
JDK (1.1.8), but other than that the only ones of which I am aware are one
in the Xerces XML parser, which we use, and two in TclBlend itself (in
Interp and CObject). I had hoped that by now someone would have discovered a
problem with the TclBlend finalizers. Perhaps this example has uncovered
one.
Jeff Sturm wrote:
> 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
