Hi Nikolay!
On 10/18/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
Evgueni,
> > first of all I'd like to emphasize that suspend/resume_all functions
> > are potentially unsafe
> > and should be used with care.
> >
> > secondly, those methods were designed mainly to support
> > stop_the_world_enumeration
> > and thus usually being used under certain conditions.
>
> hmmm... it is strange to hear words like that. TM provides
> specification for this particular method and it should perform
> according to that specification. I as a developer don't want to care
> about particular use case scenario.
I'd say that w/o stop_the_world enumeration we would not include this function
to the interface, and w/o Thread,stop()(which is deprecated and
jvmtiThreadStop which is
used in debugger) we would not include even suspend function to the
interface, like pthread or original version of hythread.
Most of the others implementations have some special notes about suspend:
MSDN:
"This function is primarily designed for use by debuggers. It is not
intended to be used for thread synchronization."
HP pthread_suspend_np(not portable):
"This functionality enables a process that is multithreaded to
temporarily suspend all activity to a single thread of control. When
the process is single threaded, the address space is not changing, and
a consistent view of the process can be gathered."
So, this function is unsafe, and should be used with care and "In
specific, with a solid model of system behavior in mind."(c) Weldon;
I agree it is required to have a solid model in mind. I also believe
it is required to have such design/implementation which doesn't allow
to break that model.
And returning to the question of safepoints inside suspend_disable
regions, we have a lot
of such places inside a VM and suspend_all is probably the only place
where this safepoint was left intentionally(I mean cyclic suspends).
It's ok to have safe points inside disabled regions only if it is
really safe to enable GC at that point. All such cases should be taken
with extreme caution. In our particular case we can't guarantee that
it is safe to suspend the thread. That's why I think having something
like assert(hythread_is_suspend_enabled) in the beginning of
hythread_suspend_all is really required? Of cause it will require some
changes in VM and TM...
> Nikolay, I understand there is only one use case for now. Again I
> expect the method works according to the spec but not how it is used
> in some particular case. Could you clarify what you mean by saying
> "Till now suspend_all method was designed to work within one group(in
> particular default group, containing java
> threads), and called be GC." Why do you have such restriction? Where
> it is specified?
We have such restrictions, because it's extremly hard to implement
common(not only for GC + limited use of TI). The spec on
suspend/suspend_all function usage scenarious can be found at:
drlvm/trunk/vm/thread/doc/ThreadManager.htm paragraphs 6.2 and 6.3
Could you give the most impossible thing to do? I was thinking of TM
as of quite independent component. But now it seems like some parts of
it are really depend on DRLVM implementation. :-(
Thanks
Evgueni
Thank you.
Nik.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
