[Tcl Java] Re: possible memory.
That may be true for your specific case. Though, it is not true in general. One could also potentially delete the interpreter without removing the thread. For example, one may be using a pool of Java threads to do some work. One thread is retrieved, creates a Tcl interp, do some work, delete the interp, goes back into the thread pool. The thread itself is never deleted, only the resources used by the thread. TclBlend allows a Tcl program to use Java. It also needs to work the other direction, which is allowing a Java program to use Tcl. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Dan Wickstrom [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 22, 2000 11:53 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Tcl Java] Re: possible memory. Jiang Wu wrote: Let's not forget there is a problem with the putting object on a queue for deletion by the interpreter. As the GC may run at a random time, it is possible when a Cobject is being finalized, the associated interpreter is already deleted. 1. Create a thread, 2. Add a Tcl interpreter 3. Do some Tcl work 4. Delete the Tcl interpreter 5. Delete the thread 6. GC runs to finalize objects created in the above process It seems that we're preventing this by having the thread cleanup routine detach the jvm thread. All of the java objects would be finalized when the thread was detached. Of course, maybe I don't understand what you mean. In aolserver, the case that you're talking about would never happen. -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 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
[Tcl Java] Re: possible memory.
On Tue, 24 Oct 2000, Jiang Wu wrote: That may be true for your specific case. Though, it is not true in general. One could also potentially delete the interpreter without removing the thread. For example, one may be using a pool of Java threads to do some work. One thread is retrieved, creates a Tcl interp, do some work, delete the interp, goes back into the thread pool. The thread itself is never deleted, only the resources used by the thread. TclBlend allows a Tcl program to use Java. It also needs to work the other direction, which is allowing a Java program to use Tcl. -- Jiang Wu [EMAIL PROTECTED] Yeah, that is a nasty one. We really need to create a good document that details all of these create/destroy cases. In this case, the thread would hold the same notifier but the interp it was create in would be different. I am not sure if this would blow things up. It might be enough to put a call to System.gc() in the Interp destroy callback. Not only do we need to doc this, but we need regression tests for these edge cases too. I have been thinking about how to include thread tests in the existing regression test suite, I think a --with-thread option that points to where the Thread extension is build is the only way to go. 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
[Tcl Java] TclObject problem
There seems to be a problem with how TclObject and Tcl_Obj are related. Regardless of what we do to fix the GC problem, using queue or using reference counting, this problem can lead to very undesirable behavior. See the stack overflow problem posted before. Tcl_Obj and TclObject should really be peers to each other. Logically, they should be on equal footing. Tcl_Obj is used in C functions to access the real data (the internal representation), while TclObject is used in Java to access the real data (the internal representation). The internal representation may be in C or Java. The whole thing should look like this: Tcl_Obj -- equivalent to -- TclObject | | \ internal rep -/ | V Java Object or C Object The current implementation makes TclObject dual purpose. Sometimes, a TclObject is just a Java version of Tcl_Obj. Other times, a TclObject is the internal rep of a Tcl_Obj. This dual role causes some confusion. Same thing is true for Tcl_Obj. Sometimes, Tcl_Obj is a C reference to TclObject. Other times, it is an internal rep of a TclObject. Take a look at TclObject.setInternalRep() on how TclBlend tries to toggle the role played by a Tcl_Obj from being an internal rep into a C reference to TclObject. But, where is the similar code for toggling the roles played by a TclObject? We really care about this issue because the C Tcl interpreter makes the basic assumption that a Tcl_Obj can change its internal rep into different forms. Suppose the interpreter gives us a Tcl_Obj, we are free to convert its internal rep into different forms, integer, string, or list. The interpreter should still have the same access to the data regardless of its internal form. This doesn't happen in TclBlend. Take this example: TclObject (A) contains -- Tcl_Obj (B) contains | V C string internal rep (C) TclBlend returns (A) into the Java code to represent (B). The interpreter understands (B). Assuming the original internal rep (C) is a simple C string containing an integer. TclBlend is free to alter the internal rep into a TclInteger. We now have: TclObject (A) -- is contained by Tcl_Obj (B) contains | V TclInteger (D) The new internal rep is a Java object, TclInteger (D). So far so good. Let's do the internal rep conversion one more time. This time, let's make the internal rep into a list using TclList.setListFromAny. We end up with: TclObject (A) -- is contained by Tcl_Obj (B) | V contains -- Tcl_Obj (E) contains | V C Tcl_List internal rep (F) This is wrong. We did not arrive back at where we started. The Tcl interpreter and the Java program are looking at different objects now. I was testing out this behavior and found the stack overflow bug. In addition, the memory loss reported by Dan is also related to this problem. Object (E) is wrongly introduced. The interpreter does not know about (E). The interpreter is expecting object (B) to change form instead. Therefore, the interpreter would clean up (B) and leave (E) to dangle. The correct answer to the above conversion should be: TclObject (A) contains -- Tcl_Obj (B) contains | V C Tcl_List internal rep (F) If this were the case, then there would be no memory loss. -- Jiang Wu [EMAIL PROTECTED] 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
[Tcl Java] Re: ajuba branch
On Tue, 24 Oct 2000, Dan Wickstrom wrote:
I've finished the changes that I need to make for making the notifier
thread safe, and I want to generate a patch against the ajuba contract
branch, so I checked it out from sourceforge and built it. When I run
make test, I get an assertion failure. on tsdPtr-initalized. Is this
branch supposed to be able to run the tests, or do I need to wait for
other changes? I was hoping that the tests would pass before I made the
notifier changes, so that I could at least tell if the new notifier
changes would break anything.
I'm running with the following:
redhat 6.2
tcl8.3.2
tcljava from souceforge ajuba contract branch
blackdown jdk1.1.8_v1
That really should work, everything you are using is
the same as my install except I have the CVS version of Tcl.
When I run the "make test" on the contract
branch, it works just fine. Of course, I am using
IBM JDK 1.3. not the blackdown one. I know there
is a problem with a core dump during some of the
classloader tests when run with JDK 1.1.8 from
blackdown, but you never hit that assert. The
assertion is raised in the case where a JNI function
is called in a thread before the thread local class
cache and JNI thread attach have been done.
... (Time passes) ...
I just tried it with JDK 1.1.8 and now I am getting
a SIGILL in some pthreads code. Very strange.
#0 0xbfffa6ee in ?? ()
#1 0x400dbe05 in pthread_handle_sigrestart (sig=32, ctx={gs = 0, __gsh =
0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 0,
esi = 3221211404, ebp = 3221211844, esp = 3221211372, ebx = 3221211404,
edx = 1074683196, ecx = 0, eax = 0, trapno = 1, err = 0, eip =
1075407969, cs = 35, __csh = 0, eflags = 2097734, esp_at_signal =
3221211372, ss = 43, __ssh = 0, fpstate = 0xbfffc870, oldmask = 4, cr2 =
0}) at pthread.c:636
#2 signal handler called
#3 0x40196c61 in __libc_nanosleep () from /lib/libc.so.6
#4 0x400d8fee in pthread_cond_timedwait_relative_new (cond=0x8164d38,
mutex=0x804a0b0, abstime=0xbfffcaf8) at condvar.c:318
#5 0x400d9211 in pthread_cond_timedwait (cond=0x8164d38,
mutex=0x804a0b0, abstime=0xbfffcaf8) at condvar.c:381
#6 0x400b3190 in Tcl_ConditionWait (condPtr=0x804a0a0,
mutexPtr=0x400c92ac, timePtr=0x8049d38) at
/home/mo/project/tcl/unix/../unix/tclUnixThrd.c:686
#7 0x400b3ccc in Tcl_WaitForEvent (timePtr=0x8049d38) at
/home/mo/project/tcl/unix/../unix/tclUnixNotfy.c:742
#8 0x4008e090 in Tcl_DoOneEvent (flags=-3) at
/home/mo/project/tcl/unix/../generic/tclNotify.c:889
#9 0x40061949 in Tcl_VwaitObjCmd (clientData=0x0, interp=0x804de48,
objc=2, objv=0xbfffcc38) at
/home/mo/project/tcl/unix/../generic/tclEvent.c:960
Since I do not see this is the IBM JDK, I am going to
assume that it is a JDK 1.1.8 bug. I hear there is
also a new JDK 1.2 and JDK 1.3 from blackdown, but
I have not downloaded those for testing.
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
[Tcl Java] Package require java fails
Hi I am trying to use tclblend. When I start tclsh, and type "package require java" it gives me an error message: "can't find package java" What should I do to rectify this error. What environment variables should I set for this? Would appreciate if someone could help me on this. Thanks sai 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
