Mo DeJong wrote:
> On Sat, 21 Oct 2000, Dan Wickstrom wrote:
>
> > >
> > > What does your src/tclblend/tcl/lang/CObject.java finalize()
> > > method look like? I thought the last round of patches left
> > > that ptr dangling on purpose. I have not has time to
> >
> > Yes the finalize method just calls the super class finalize method.
>
> Well, that would be your memory leak :)
I realize that now, but I think the idea behind Jiang's reference counting changes
was to explicitly increment/decrement the reference count as needed similar to what
is done in the native tcl code. I think there are still quite a few things that
need to be fixed to make this work, because the current code makes alot of
assumptions based on the fact that the CObject finalizer takes care of the Tcl_Obj
cleanup. I think that it's still doable, but probably alot more work would be
needed to make the reference counting work right.
> Yes. The tricky part is going to be changing the C code to support
> this. We are going to need to have the ability to enque a TclEvent
> in the GC thread, but we need an interp handle for that.
>
> Here is that I am currently looking into:
>
> A CObject() is created by calling
> newInstance() from JNI code.
> But, we don't have a handle to
> an interp in the calling code.
>
> We need to wrap this into an
> object along with the interp
> handle and put it into a table
> somewhere so that the wrapped
> object can not get GCed.
>
> class CObjectCleanupTable {
> static void addObjRef(Interp i, long ptr)
> static void deleteObjRef(long ptr)
> static void finalizeObjRef(long ptr)
> }
>
> It seems like we could change the
> CObject.newInstance() signature, so
> that the Interp object would need
> to get passed along too.
>
> (Old)
>
> private static TclObject
> newInstance(
> long objPtr) // Tcl_Obj to wrap.
> {
> return new TclObject(new CObject(objPtr));
> }
>
> (New)
>
> private static TclObject
> newInstance(
> Interp interp, // Current Interp
> long objPtr) // Tcl_Obj to wrap.
> {
> return new TclObject(new CObject(interp, objPtr));
> }
>
> This means that any place where CObject.newInstance()
> (only JavaGetTclObject at this point) is called would
> also need to include the Interp parameter.
>
> Now the CObject ctor could register the given objPtr
> like so:
>
> CObject(
> Interp interp, // The current Interp
> long objPtr) // Pointer to Tcl_Obj from C.
> {
> this.objPtr = objPtr;
> incrRefCount(objPtr);
> CObjectCleanupTable.addObjRef(interp, objPtr);
> }
>
> Then in the finalize method we would do this:
>
> protected void finalize() throws Throwable
> {
> if (objPtr != 0) {
> /*
> * If the object is finalized while the reference is still valid,
> * we need to sever the connection to the underlying Tcl_Obj*.
> */
>
> CObjectCleanupTable.finalizeObjRef(objPtr);
> }
> super.finalize();
> }
>
> That would enqueue a TclEvent that would end up calling
> CObject.decrRefCount(objPtr) inside the thread where
> the Tcl_Obj was created.
>
> I think it is doable, but some hacking is going to
> be required.
It seems like it would work.
> > > We also need to make the Tcl Blend Notifier thread
> > > safe. I think time would be better spent focusing
> > > on that right now instead of fighting ref counting.
> >
> > Is this just a matter of modifying the Notifier class so that there
> > is an event queue per thread instead of a global queue as there
> > is now. Are there any modifications necessary in the 'c' code?
>
> Making the Notifier "thread safe" is actually the easy part.
> All you would need to do is add another field to the Java
> interp structure that would store the "Tcl Thread ID" value.
> You would get the thread id in the pkg init code, and then save
> it into the Interp structure.
>
> ThreadID curThread;
> GetCurrentThread(&curThread);
> /* put into interp field */
>
> This TclThreadID is needed so that you can call the
> Tcl_ThreadAlert(ThreadID) from inside the Notifier
> code.
>
> Once that bit is in place, you would then need to
> rip out the current notifier implementation.
> Start with the Jacl impl of Notifier and
> copy it into the Tcl Blend dir. Now merge any
> diffs over from the Tcl Blend impl but leave
> out all of the "global notifier" crap. The
> only thing to watch out for is to keep
> Jiang's fixed for deadlocking in the
> Notifier queue. I don't think that
> patch ever made it into Jacl so
> don't copy that bit (see ChangeLog
> entry on 2000-08-23).
>
> Now it is just a matter of going in a deleting
> all the unused C code that was used to implement
> the old notifier. That part should be fun cause
> there is just a gob of nasty code in there and
> one quick press of the delete button will finish
> it off.
>
> Are you up to it? I am going to be working on
> this object ref queue thing for some time,
> so if you could take a whack at the Notifier
> it would really help. There is not going to
> be much overlap in these changes, so they
> can be done in parallel.
I'll see if I can take a look at this later in the week. It doesn't sound like it
would be too difficult to do.
-Dan
----------------------------------------------------------------
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
