[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] another deadlock
On Mon, 19 Jun 2000, Jiang Wu wrote: Would the GC problem still exist if the underlining Tcl is thread enabled? In other words, is it OK to call "FreeTclObject()" from any thread in the thread enabled Tcl? It may not be a good idea to block the GC thread. For this scheme to work, one needs to make some assumption about how the GC works, which may not apply to the various implementation of the JVM. I like the other approach. Tcl/TclBlend should clean up its own data in a Tcl safe manner. This probably means that the user of TclBlend needs to explicitly free Tcl objects using "TclObject.preserve()" and "TclObject.release()". Tcl Blend users should be doing this already. Then, when the Java GC is invoked to clean up the associated Java object, the GC need not access any Tcl stuff. Though, I am not sure about automatically creating a list of objects to be finalized. Perhaps if we let the GC thread access only 1 "Tcl thing", then we can make that single function thread safe so that both the GC thread and Tcl can call it at any time. This function could keep a linked list of Tcl internal reps that would need to be freed by Tcl. Of course, this means we would need a thread enabled Tcl. 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] Re: [Tcl Java] Re: [Tcl Java] another deadlock
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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] another deadlock
Mo DeJong wrote: I am not sure what volatile has to do with anything. I was under the impression those were for serialization. Volatiles are potentially useful because loads/stores are guaranteed to occur in order (if the VM is implemented correctly). There are certain idioms based on volatile that produce correct behavior in multithreaded code even without `synchronized' blocks. 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. Yep. I do have GC patches for 8.3.1, if anyone is brave and/or desperate... 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. OK, how do you want to proceed? I'm thinking about thin locks, but I don't know how they can be done portably and reliably. SPARC users can use ldstub, for example... -- Jeff Sturm [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: [Tcl Java] Re: [Tcl Java] another deadlock
Mo DeJong wrote: What is a "thin lock"? Did you mean spin lock? I don't see what is wrong with a good old mutex, but putting one in means we would need to require a thread safe version of Tcl. I don't really like the "use the JVM to do locking" hacks in there now. Using the JVM to do locking in a JVM finalizer seems like a really bad idea. Thin locks are usually performed in user space, i.e. without help from the OS kernel. Spin locks are an example. A mutex might work, but isn't really portable either... depends on the OS. -- Jeff Sturm [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: [Tcl Java] Re: [Tcl Java] another deadlock
On Mon, 19 Jun 2000, Jeff Sturm wrote: Mo DeJong wrote: What is a "thin lock"? Did you mean spin lock? I don't see what is wrong with a good old mutex, but putting one in means we would need to require a thread safe version of Tcl. I don't really like the "use the JVM to do locking" hacks in there now. Using the JVM to do locking in a JVM finalizer seems like a really bad idea. Thin locks are usually performed in user space, i.e. without help from the OS kernel. Spin locks are an example. A mutex might work, but isn't really portable either... depends on the OS. Ahh, but Tcl provides a portable locking layer when compiled with threads support. That is what I am sugesting we use for the mutex. If we require Tcl thread support, we can get rid of the Java monitor used in JAVA_LOCK. Anything to avoid calling a JNI method is a plus in my book. 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] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] another deadlock
Mo DeJong wrote: Ahh, but Tcl provides a portable locking layer when compiled with threads support. That is what I am sugesting we use for the mutex. OK, I hadn't thought of that. (I am trying to augment my Java code with Tcl, not the other way around... that colors my viewpoint a bit.) If we require Tcl thread support, we can get rid of the Java monitor used in JAVA_LOCK. Anything to avoid calling a JNI method is a plus in my book. I agree. Good idea. -- Jeff Sturm [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: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] another deadlock
So, pardon my desperation, but are you gentlemen going to save my job and give me a TclBlend 1.2.5 patch to try out? Jeff Sturm wrote: Mo DeJong wrote: Ahh, but Tcl provides a portable locking layer when compiled with threads support. That is what I am sugesting we use for the mutex. OK, I hadn't thought of that. (I am trying to augment my Java code with Tcl, not the other way around... that colors my viewpoint a bit.) If we require Tcl thread support, we can get rid of the Java monitor used in JAVA_LOCK. Anything to avoid calling a JNI method is a plus in my book. I agree. Good idea. -- Jeff Sturm [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 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
