harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] is harmony-1951 a bug or a feature?
Date Tue, 21 Nov 2006 14:32:52 GMT
I ran Rana's modified Test2.java.  I do see a problem.  This may be a
situation where there are multiple bugs involved.  To make sure we
accurately describe each bug, the problem I see is the jvm hangs after
printing:

"Will start two threads which will wait on the same monitor"
"Both threads are waiting now, will interrupt the second one"

I am able to break into the hung DRLVM with microsoft debugger and see the
state of each thread:

1)
Java_java_lang_VMThreadManager_wait( waits forever)  -- get_vm_thread() is
at the  base of the stack.  I think is the system startup thread and does
not run any app code.
2)
Java_java_lang_VMThreadManager_wait (waits forever) -- from a _threadstartex
3)
Java_java_lang_VMThreadManager_sleep( sleeps 10 msec) -- from a
_threadstartex.  This thread has harmonyvm.dll!_TerminateThread() and
compile_jit_a_method() on its stack.  This might be because this thread is
trying to die.  I can set a breakpoint in DRLVM jthread_sleep() and observe
that this thread does indeed run every 10 msec.  Meanwhile the other two app
threads appear to be waiting forever.
4)
Java_java_lang_VMThreadManager_wait( waits forever) -- from a _threadstartex

My hunch is that somehow the line of app code, "Test2.toStop.join()" is not
being handled properly.  In otherwords, a bug in DRLVM's implemention of
Thread.join().

Rana, Geir, is the above what you are seeing?





On 11/20/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> Oh, this is bad.  Rana, good catch - we need to fix this ASAP.  It's an
> amazingly simple test.  Hangs on x86_64 linux too.
>
> geir
>
>
> Rana Dasgupta wrote:
> >
> >
> > On 11/20/06, *Weldon Washburn* <weldonwjw@gmail.com
> > <mailto:weldonwjw@gmail.com>> wrote:
> >
> >     On 11/20/06, Geir Magnusson Jr. < geir@pobox.com
> >     <mailto:geir@pobox.com>> wrote:
> >      >>
> >      >> I guess the important question is "does it matter?"
> >
> >
> >      >Until someone brings in a real app that shows existing behavior is
> a
> >      >problem, it probably does not matter.  I am inclined to close 1951
> >     with "not
> >      >a bug".
> >
> >
> > Hi,
> >    I looked at Geir's interesting test case in 1951. It is always
> > somewhat suspicious when a behaviour is significantly different from RI.
> > As it stands, it does not look like a bug. Ordering is strictly
> > specified only for memory related operations. The java memory model with
> > respect to same thread operations ( the main thread in the test case )
> > only specify that reads and writes to the same location are in order...
> > other operations ( in this case the asynchronous operations resulting
> > from the interruption of the two threads ) have no pre-ordering....it is
> > only intuitive  to expect the asynch operations to complete in the order
> > the program issues them.
> >
> >   Without breaking the memory model, it would in fact, be also possible
> > for an optimizing jit to reorder the operations to issue the interrupt
> > on the toWait(true) thread before issuing the interrupt on the
> > toWait(false) thread.
> >
> >   However, while playing with the test case, I modified it to force a
> > strict ordering in the completion of the asynch operations...forcing the
> > toWait(false) thread to finsih before the toWait(true) thread. RI
> > produces output as expected, however drlvm hangs......this does point to
> > some problems in the DRLVM thread scheduler....( which I think is also
> > showing up in the original test program, but unfortunately cannot be
> > proved ). I am attaching the case...
> >
> > Thanks
> > Rana
> >
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message