Weldon,
If the "current scheme" is the same that we had 1 or 2 years ago, the answer
is no
This is just the same scheme!
I am really hoping that all of this is simply an implementation
bug.
There are no open issues on this scheme, there is no examples that
fail right now because of the suspend_all.
The bottom line is that to make the system easy to reason about, a
thread should always be in suspend_enable mode before it does anything that
might block.
We already talk about that in the top of the thread. I agree with
that, and will add some debug capacity to the TM.
Eugeny,
Actually, the code is not ideal, and there is a lot of things to do on it.
You could contribute you ideas into the code, and test them.
The suspend_all code contains a number of compromises that was
produced by different workloads and stress tests failures.
I attach patch that implement one of you ideas: to hold global thread
lock between
suspend_all / resume_all.
As I remember it could cause deadlock in JVMTI. Probably, something
change in mean time.
Thanks
Artem
Index: vm/thread/src/thread_native_suspend.c
===================================================================
--- vm/thread/src/thread_native_suspend.c (revision 464417)
+++ vm/thread/src/thread_native_suspend.c (working copy)
@@ -420,7 +420,7 @@
}
hythread_iterator_reset(&iter);
- hythread_iterator_release(&iter);
+ //hythread_iterator_release(&iter);
if(t)
{
*t=iter;
@@ -450,6 +450,8 @@
}
hythread_iterator_release(&iter);
+ hythread_iterator_release(&iter);
+
return TM_ERROR_NONE;
}
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
