Re: [Sablevm-developer] sablevm hang

[Chris P. <chr...@ma...>]

Joseph Paris wrote:
> I've done some testing with sablevm and calling methods for awt, and i 
> haven't had a problem.  For example, instantiating an AWT or Swing class 
> from inside another class there were no problems.  If i remove that call 
> in code, it then hangs on the instantiation of an AWT/Swing class one line 
> later.

I'm sorry, I don't follow 100%.  Can you illustrate with code?

   The hang happens every time (and i've tried about 40+ times to
> make sure ;p).  I'm really not sure why it would hang there, and i know 
> there is no problem using Sun's jvm.

Okay.  That's very fortunate that it happens every time :)

> I'm not too familiar on how your vm works.  Do you create a thread per 
> class that's loaded, etc?

There is one pthread per Java thread.

   I wish i had a more simple test case to work
> with.  What are the relevant files i should be looking at?

Check out the staging versions of sablevm and sablevm-classpath (which 
are fairly stable, but contain more recent updates than the tarballs). 
You could also grab the latest nightly snapshots.  See:

http://devel.sablevm.org/wiki/Getting

As for relevant files ... well, there's Java stuff in sablevm-classpath, 
and VM stuff in sablevm.  You might want to try

./configure --enable-debugging-features --with-threading=switch

for the most safe mode.  The switch interpreter is easier to step 
through with gdb.

I tried it with an older (roughly 1.1.4) sablevm-switch-debug and it 
still hangs.  I changed the _svmf_dump_stack_trace() function to print 
out internal frames, and I see:

stack_bottom_method
(VMObject.java:-1)  java/lang/VMObject.wait  n
(Object.java:445)  java/lang/Object.wait
(EventQueue.java:98)  java/awt/EventQueue.getNextEvent
(EventDispatchThread.java:64)  java/awt/EventDispatchThread.run
(VMThread.java:116)  java/lang/VMThread.callRun
(Thread.java:386)  java/lang/Thread.callRun
(VirtualMachine.java:117)  java/lang/VirtualMachine.runThread
vm_initiated_call_method
stack_bottom_method

which at first glance suggests the other thread (at the top) never even 
gets started properly.  I might be wrong, but it looks related to some 
thread startup errors we were seeing earlier.  Etienne and Greg, I put 
Joe's current test case with an added main method at:

http://www.sable.mcgill.ca/~cpicke/sablevm/AwtUtils.java

   I will
> continue to try and replicate this problem in a more simple case.

Sure.  Basically every line or possibly funny syntax (e.g. anonymous 
classes) that you can eliminate cuts down the problem.

Cheers,
Chris