harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Aliev" <artem.al...@gmail.com>
Subject Re: [drlvm][threading] is harmony-1951 a bug or a feature?
Date Tue, 21 Nov 2006 15:55:34 GMT
Guys,

I attach a kind of fix for the problem to the JIRA, but I'm not sure I
want to commit such fix.
Please review and comment

Thanks
Artem


On 11/21/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> 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
View raw message