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 <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > On 11/20/06, Geir Magnusson Jr. < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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
