Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of alexander.n.alexeev@gmail.com
 designates 64.233.162.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=PQ156lftdXeROCBigW5xv6FXChczDzDmngi29QSNnPbsbHfuvtHL0tq4AUWyg2D+Qm6vuumfReahZ+SgwYiUH4MHlI6CtXGCtqLS4S8zPJTMLF4yoe0WXNkk/BnToZAh7QZ3JE/KNrIev+0zg8Kcpzh6Cebs42aG/T9J6NSlzEY=
Message-ID: <9edfd6e10710080626x6a4f32fcqf653be29ccd88391@mail.gmail.com>
Date: Mon, 8 Oct 2007 17:26:43 +0400
From: "Alexander Alexeev" <alexander.n.alexeev@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
In-Reply-To: <4dd1f3f00710060834g6da02ab2j32888dd47a80962e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9edfd6e10710050555l3cd92949x3fc01b9578cf1ae5@mail.gmail.com>
	 <ca4b22060710050716l6394d742uca83fba28f15fe71@mail.gmail.com>
	 <9edfd6e10710050844i1512f4c3ycac0443973318e2d@mail.gmail.com>
	 <4dd1f3f00710060834g6da02ab2j32888dd47a80962e@mail.gmail.com>

Hi.

I've created HARMONY-4905.
Test case attached.

Alex.

On 10/6/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> Alexander,
>
> Would it be possible for you to write a simple test that demonstrates
> the inconsistent behavior?
>
> On 10/5/07, Alexander Alexeev <alexander.n.alexeev@gmail.com> wrote:
> > Pavel, looking on the code I can't understand why different events are
> > sent just before wait thread is blocked inside lock.wait(). In both
> > cases JVMTI_EVENT_MONITOR_WAIT should be sent, there is no contention
> > for monitors on enter to lock.wait().
> >
> > Is wait thread blocked inside lock.wait() before waited thread terminated?
> >
> > Maybe you misunderstand me.
> > Lets define two threads :)
> > T1 - long running job
> > T2 - is waiting for T1 termination
> >
> > I am interested in event which is rose just after T2 calls join method
> > for T1, and T1 still continue execution and T2 become blocked and
> > wait.
> >
> >
> > > 2. Should it be? What is proper thread's state depiction?
> > I think it should. Proper state is "wait" because it corresponds with
> > expectation about what is happening with thread, it is waiting another
> > termination but isn't competing for monitor.
> > Also it corresponds with other VMs behavior.
> >
> > Thanks.
> > Alex.
> >
> > On 10/5/07, Pavel Rebriy <pavel.rebriy@gmail.com> wrote:
> > > Hello Alexander
> > >
> > > Here is an instance of  Thread.join() implementation:
> > >
> > >     public final void join() throws InterruptedException {
> > >         synchronized (lock) {
> > >             while (isAlive()) {
> > >                 lock.wait();
> > >             }
> > >         }
> > >     }
> > >
> > > If joined thread is dead we don't go to wait and the last event is
> > > JVMTI_EVENT_MONITOR_CONTENDED_ENTER. In case of the following code:
> > >
> > >     public final void join() throws InterruptedException {
> > >         synchronized (lock) {
> > >             do {
> > >                 lock.wait();
> > >             } while (isAlive());
> > >         }
> > >     }
> > >
> > > the last event will be JVMTI_EVENT_MONITOR_WAIT. So the answers are:
> > >
> > > 1. No, such kind of behavior is not defined in spec.
> > > 2. Should it be? What is proper thread's state depiction?
> > >
> > >
> > > On 05/10/2007, Alexander Alexeev <alexander.n.alexeev@gmail.com> wrote:
> > > >
> > > > Hi, All.
> > > >
> > > > I've faced the following difference in Harmony JVM TI behavior in
> > > > comparison with other JVMs.
> > > >
> > > > When one thread spawns another and joins it, waiting for its
> > > > termination, it becomes blocked on monitor  (from last handled event
> > > > JVMTI_EVENT_MONITOR_CONTENDED_ENTER for that thread before 'sleep") ,
> > > > while in other VMs (Sun's, IBM's and BEA's) thread which calls "Join"
> > > > starts waiting (last event is JVMTI_EVENT_MONITOR_WAIT before
> > > > 'sleep"). Probably set of events depends on VM internals, but in
> > > > common sense "waited" state is more suitable for thread which waits
> > > > for other thread termination.
> > > >
> > > > 1. Can such kind of behavior be defined in any specs?
> > > > 2. Could it be fixed, i.e. from blocked to waited state during join?
> > > > This is required for proper thread's state depiction in tools.
> > > >
> > > > Alex.
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Pavel Rebriy
> > >
> >
>
>
> --
> Weldon Washburn
>