ons 2004-10-20 klockan 18:47 +0200 skrev Guilhem Lavaux:
I have now tested the new code a bit. I have succeeded to hang it once after about 5 hours of testing (but that could be related to the problem below) but it is much more stable than any other kaffe version I have tested.
That's some good news! thanks!
I have however found out empirically that KGC_rmRef() in tDispose() somehow uses the thread local kSem, so KaffeVM_unlinkNativeAndJavaThread (which calls ksemDestroy) needs to be invoked after that, not before. Applying the attached patch fixes fairly frequent lockups with Fedora Core 2.92 (it takes about a minute to reproduce the lockup).
Thanks, I've committed the patch.
Random thoughts:
- in unlinkNativeAndJavaThread(), the only unlinking that takes place seems to be that the jniEnv member is set to 0. Since this is the last time (?) the thread_data structure is ever accessed the value of jniEnv shouldn't matter to anyone. Therefore the name unlinkNativeAndJavaThread is not only ugly but also misleading :P
Yeah. Feel free to refactor the name to something else.
- since the thread local ksem seems to be used by a variety of seemingly unrelated code (locking, the gc interface) It is important that it is initialized as early as possible and destroyed as late as possible in a thread's life cycle. It is also important that this is only called for new and not for reused threads (not that we have any atm).
We could add a 'status' field to ksem in debugging mode to represent its known status: initialised/destroyed and add asserts for ksem operations to check if the status is ok (again when debugging is enabled).
cheers, dalibor topic
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
