harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][threading] Thread.suspend() causes thread_native_fat_monitor.cpp::monitor_wait_impl() to give up the monitor
Date Thu, 07 Dec 2006 11:22:13 GMT
On 12/7/06, Ivan Popov <ivan.g.popov@gmail.com> wrote:
> Weldon,
>
> JDWP spec states that the thread should be suspended by an event in
> Java code or by a user request. In both cases suspended thread can be
> resumed later by a user request, regardless of the way it was
> suspended. JDWP spec does not dictate how this should be implemented,
> and this particular implementation is just our approach to implement
> JDWP specs correctly. Other JDWP implementations may use different
> algorithms.
>
> We tested our JDWP agent with JRockit and Sun JRE and it works fine
> with both JREs. We also tried to run JDWP agent from JRockit JRE
> (which is probably the same to what Sun JRE has) and found out that
> this agent works unstable with DRLVM. Unfortunately, we could not
> investigate what was the problem, because we don't have sources of
> this agent and don't know details of its implementation.

I do believe it is still possible to investigate the problem even
without JDWP sources. Though it can be harder to do .....

Thanks
Evgueni

>
> Thanks.
> Ivan
>
> On 12/6/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > Ivan,
> > This makes perfect sense.  One question.  Is the below protocol in the JDWP
> > spec?  In other words, will we hit different deadlocks when different JDWP
> > agents are plugged into Harmony?
> >
> >
> > On 12/5/06, Ivan Popov <ivan.g.popov@gmail.com> wrote:
> > >
> > > Evgueni,
> > >
> > > As this concerns JDWP agent algorithm, I can provide details. JDWP
> > > agent uses Thread.wait() to be sure that the thread is suspended in a
> > > right place inside JVMTI callback. The precise algorithm is the
> > > following:
> > >
> > > 1. Java thread T1 enters JVMTI callback and acquires M1.
> > > 2. Java thread T1 is waiting on M1, and thus releases M1.
> > > 3. Agent thread T2 acquires M1.
> > > 4. Agent thread T2 calls suspend on Java thread T1.
> > > 5. Agent thread T2 calls notify on M1.
> > > 6. Agent thread T2 releases M1.
> > > ... some debugging actions are performed which may include acquiring
> > > M1 by threads.
> > > 7. Agent thread T2 acquires M1.
> > > 8. Agent thread T2 calls release on Java thread T1.
> > > 9. Agent thread T2 releases M1.
> > > 10. Java thread T1 finishes waiting, and acquires M1.
> > > …
> > >
> > > The problem is on the step 6. After thread T2 has notified suspended
> > > thread T1 and released monitor M1, this monitor is eventually locked
> > > by thread T1, which is still in suspended state and thus should not
> > > lock monitor or perform any other actions. However, monitor is
> > > incorrectly locked by T2 for a while, and other threads hang trying to
> > > acquire it while performing debugging actions, or thread T2 hangs in
> > > step 7 acquiring monitor M1 before releasing T2.
> > >
> > > Thanks.
> > > Ivan
> > >
> > > On 12/5/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > > > On 12/5/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
> > > > > Evgueni, Weldon,
> > > > >
> > > > > 1) NO_COND_VARS code will go to the trash soon, see HARMONY-2269
for
> > > > > details, Salikh has already prepared patches for this.
> > > > >
> > > > > 2) I agree, that this code is looks like (and there is) a workaround
> > > > > to let jdwp agent proceed with its usual scenarios for breakpoints.
I
> > > > > will prepare testcases soon today, but in short the problem here
is
> > > > > the following:
> > > > >
> > > > > 1. Thread T1 is waiting on monitor M1.
> > > > > 2. Thread T2 calls suspend on thread T1.
> > > > > 3. Thread T2 calls notify on  M1
> > > > > 4. Thread T1 finishes waiting, acquires M1 and falls into safepoint
> > > > > 5. Thread T2 calls monitor enter (M1) and Blocks on M1 (deadlock)
> > > >
> > > > Nikolay,
> > > >
> > > > I tend to think that the real problem is in the above scenario. T2
> > > > suspends T1 advisedly. So T2 should be ready that T1 may block while
> > > > holding all its monitors not only M1. (for example T1 may hold M2 as
> > > > well). If T2 tries to get M2 it will block on M2.....
> > > >
> > > > To have more complete understanding what is going in here I need one
> > > > more piece of information. To be able to perform step 3 the T2 must
> > > > own M1. Could you show where T2 acquires M1 and where it releases it?
> > > >
> > > > Thanks
> > > > Evgueni
> > > >
> > > >
> > > > >
> > > > > The sequence above is how jdwp agent implement breakpoints. The
> > > > > workaround we discussing preventing suspended thread from acquiring
> > > > > monitor (point 4).
> > > > >
> > > > > I'm going to write several testcases on this and will file an issue
if
> > > > > we fine more elegant solution (suggestions are welcome).
> > > > >
> > > > > PS
> > > > >
> > > > > >What if suspend is requested right after "if (self->suspend_request)
> > > > > {..." statement?
> > > > > The question here is how to behave if we were suspended and notified
> > > > > after that but if we were first notified and then suspended it's
out
> > > > > of this case.
> > > > >
> > > > >
> > > > > On 12/5/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > > > > > Weldon, Nikolay,
> > > > > >
> > > > > > I can't grok how Thread.suspend() interact with
> > > > > > thread_native_fat_monitor.cpp::monitor_wait_impl(). Could you
> > > explain
> > > > > > this?
> > > > > >
> > > > > > Here is my observations regarding monitor_wait_impl()
> > > implementation:
> > > > > >
> > > > > > 1) Line:197 discards previously set value of 'status' variable.
What
> > > > > > if it is assigned to TM_ERROR_TIMEOUT value at line 193?
> > > > > > 2) The above trick with unlocking a mutex in case of
> > > 'suspend_request'
> > > > > > is not zero seems like a workaround to me. What if suspend is
> > > > > > requested right after "if (self->suspend_request) {..." statement?
> > > > > > 3) It was already discussed several times but I'll repeat it
one
> > > more
> > > > > > time. It doesn't seem to be a solid (and safe) approach when
a
> > > thread
> > > > > > with suspend state set to "disabled" calls monitor_wait_impl()
and
> > > > > > thread's state is changed to "enabled" inside monitor_wait_impl().
> > > > > >
> > > > > > Evgueni
> > > > > >
> > > > > > On 12/4/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > > > > > > The following code does not look right.  I looked in the
JVM
> > > spec.  I can't
> > > > > > > find any mention that a Thread.suspend() should cause the
target
> > > thread to
> > > > > > > give up any java lock.  I am trying to construct a test
to confirm
> > > if this
> > > > > > > is a problem or not.  Anybody have any suggestions?
> > > > > > >
> > > > > > > line 216:
> > > > > > >
> > > > > > >
> > > > > > > if(self->suspend_request) {
> > > > > > >
> > > > > > >    hymutex_unlock(mon_ptr->mutex);
> > > > > > >
> > > > > > >    hythread_safe_point();
> > > > > > >
> > > > > > >    hymutex_lock(mon_ptr->mutex);
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Weldon Washburn
> > > > > > > Intel Enterprise Solutions Software Division
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
>

Mime
View raw message