Thread.sleep() strangeness

[Matthew P. Gleeson]

I've noticed a possible-thread-related problem when I use the kaffe
interpreter, but not the jit.  I'm using the stock kaffe-0.10.0
sources on a Sun with Solaris 2.5.1.  Here's a little toy program that
creates my problem:

class Loop
{
	static final int LOOP_MAX = 10000000;

	static public void main(String args[])
	{
		for (int i=0; i<LOOP_MAX; i++)
		{
			System.out.println("LOOP: index = "+i);
			try
			{
				Thread.sleep(100);
			}
			catch (Exception e) {}
		}
	}
}

It seems to work as expected when I use the jit-enabled kaffe, but
with the intrp kaffe it never seems to come out of the first sleep
(actually just sleeps a REALLY long time).

So I look at the interpreter in gdb to see what's going on:

(gdb) break sleepThread
Breakpoint 2 at 0xef77db1c: file thread.c, line 251.
(gdb) cont
Continuing.
LOOP: index = 0

Breakpoint 2, sleepThread (time=0x0000000000111d30) at thread.c:251
251             if (time > 0) {
(gdb) where
#0  sleepThread (time=0x0000000000111d30) at thread.c:251
#1  0xef517100 in java_lang_Thread_sleep (time=0x0000000000111d30)
    at Thread.c:40
#2  0xef77ec58 in callMethodA (meth=0x0, func=0x83868, obj=0x0, 
    args=0xefffec80, ret=0xefffefb0) at support.c:300
#3  0xef78a798 in virtualMachine (meth=0x83868, arg=0xefffec80, 
    retval=0xefffefb0, tid=0xa04c8) at ./intrp/machine.c:113
#4  0xef78cbc0 in virtualMachine (meth=0xff918, arg=0xefffee90, 
    retval=0xefffefb0, tid=0xa04c8) at kaffe.def:2272
#5  0xef77efb4 in callMethodV (meth=0xff918, func=0xef77db00, obj=0xa04c8, 
    args=0xefffefb0, ret=0xefffefb0) at support.c:433
#6  0xef77e734 in do_execute_java_class_method (cname=0xeffff339 "Loop", 
    method_name=0x123f8 "main", signature=0x0) at support.c:113
#7  0x10e30 in main (argc=2, argv=0xeffff1a4) at main.c:100
(gdb) 

That time=0x111d30 parameter to java_lang_Thread_sleep doesn't really
look right at all.  When I look at the jit version under gdb, the
parameter is what I would think it would be (0x64).  

I'm new to Kaffe and I'm afraid I'm not yet manly enough to figure out
where that weird value is coming from (I was barely hanging in there
until sysdepCallMethod totally threw me).

-- 
Matt Gleeson		http://www.erc.msstate.edu/~gleeson/