You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexander Alexeev <al...@gmail.com> on 2007/10/05 14:55:51 UTC
[drlvm][jvmti] Thread's state after Join invocation is debatable
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.
Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
Posted by Pavel Rebriy <pa...@gmail.com>.
+1
On 06/10/2007, Weldon Washburn <we...@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 <al...@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 <pa...@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 <al...@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
>
--
Best regards,
Pavel Rebriy
Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
Posted by Alexander Alexeev <al...@gmail.com>.
Hi.
I've created HARMONY-4905.
Test case attached.
Alex.
On 10/6/07, Weldon Washburn <we...@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 <al...@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 <pa...@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 <al...@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
>
Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
Posted by Weldon Washburn <we...@gmail.com>.
Alexander,
Would it be possible for you to write a simple test that demonstrates
the inconsistent behavior?
On 10/5/07, Alexander Alexeev <al...@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 <pa...@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 <al...@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
Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
Posted by Alexander Alexeev <al...@gmail.com>.
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 <pa...@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 <al...@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
>
Re: [drlvm][jvmti] Thread's state after Join invocation is debatable
Posted by Pavel Rebriy <pa...@gmail.com>.
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 <al...@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