On Mon, 19 Jun 2000, Jeff Sturm wrote:
> Mo DeJong wrote:
> > I think this one is along the same lines. The finalizer thread seems
> > to be called decrRefCount() which is calling FreeTclObject(). I
> > think we need a more general solution to the problem of the
> > finalizer thread walking into an interp at some random time.
>
> My understanding of 1.1 finalizers is that calling anything that can
> allocate objects as a side effect is a very bad idea, since finalizers
> are often invoked in the first place because memory is exhausted.
Yeah, you are right. Doing anything Java related in a finalizer is
a bad idea.
> Also synchronization or anything that can cause the finalizer thread to
> block should be avoided if possible.
Agreed, blocking the GC thread is so dangerous, we need to avoid this
at all costs.
> > Can we create a queue of objects that have been finalized?
> > We could then clear this queue in a Tcl "after idle" call.
>
> Possibly. The concurrency is a little tricky to solve... you never know
> when finalization will be called or from what thread. It might be
> doable with `volatile' variables, but unfortunately volatile is not yet
> implemented in Sun's VM... that's a long story in its own right.
I am not sure what volatile has to do with anything. I was under the
impression those were for serialization.
> > Should be make the gc thread block until a given Tcl event
> > has finished? This would need to be done by adding an event
> > to the Tcl event queue and then letting the GC thread go
> > when Tcl was ready to process the event.
>
> Blocking a finalizer on 1.1 could be fatal... see above.
>
> Finalizers are evil, period. These are times I wish the Tcl core had
> garbage collection... not that I wish to start that thread (again)...
> but if it did, the finalizers could go away.
GC in the Tcl core would be really cool. Lets face it, all those
incr and decr ref counts are hard to use. If you forget one, BLAMO!
You code dies and you need to go figure out where things got hosed.
Lets focus on how we can implement a thread safe JNI method
that will store a list of Tcl internal reps that need to be
freed by the Tcl interp. We need to do this in such a way
that all Java refs for that object are dropped from the
Tcl side without calling any other JNI or Tcl methods.
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
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
