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
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
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.
No, that's the point if functionality is so safe that it's impossible
to
On 10/17/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Hello All,
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
Weldon,
I agree with what you are saying above. Do you think it makes
sense to call hythread_suspend_all in enabled state only?
Evgueni
On 10/17/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 10/17/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Hello All,
first of all I'd like to
On 10/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
Hi All,
I'd like to here you opinion regarding hythread_suspend_all and
hythread_resume_all functionality provided by TM. Actually I have to
separate questions:
1) I found that hythread_suspend_all calls
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
hmm I never thought of it that way. My initial reaction is no. Suspend
enable/disable and global thread lock are seperate, distinct concepts. The
thread lock should protect the VM internal thread structs when they
are being modified. For example, the thread lock should allow only
one
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
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.
No, that's the point if functionality is so safe that it's impossible
to break the model,
it's not so highly important(as in our case)
It seems we are not in sync I don't suggest changing current
suspention scheme...I like it I'm talking about one particular
case.and still can't see any disadvantages in what I propose...
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I agree it is required to have a solid
On 10/18/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 10/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
Hi All,
I'd like to here you opinion regarding hythread_suspend_all and
hythread_resume_all functionality provided by TM. Actually I have to
separate
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
hmm I never thought of it that way. My initial reaction is
no. Suspend
enable/disable and global thread lock are seperate, distinct
concepts. The
thread lock should protect the VM internal thread structs when they
are being
On 10/19/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 10/18/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 10/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
Hi All,
I'd like to here you opinion regarding hythread_suspend_all and
hythread_resume_all
Hi All,
I'd like to here you opinion regarding hythread_suspend_all and
hythread_resume_all functionality provided by TM. Actually I have to
separate questions:
1) I found that hythread_suspend_all calls thread_safe_point_impl
inside. There is no assertion regarding thread's state upon
Hello All,
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.
1) I found that
On 10/17/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Hello All,
first of all I'd like to emphasize that suspend/resume_all functions
are potentially unsafe
and should be used with care.
In specific, with a solid model of system behavior in mind.
secondly, those methods were designed
Evgueni Brevnov wrote:
Hi All,
I'd like to here you opinion regarding hythread_suspend_all and
hythread_resume_all functionality provided by TM. Actually I have to
separate questions:
1) I found that hythread_suspend_all calls thread_safe_point_impl
inside. There is no assertion
The simplest model is to grab the thread lock whenever thread A wants to
suspend thread B at a safepoint. While this serializes thread suspension
and can potentially be a bottleneck, let's wait until its a proven
performance problem to change this model. For thread A to be ready to grab
the
On 10/17/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
The simplest model is to grab the thread lock whenever thread A wants to
suspend thread B at a safepoint. While this serializes thread
suspension
and can potentially be a bottleneck, let's wait until its a proven
performance problem
19 matches
Mail list logo
