> 
> Hello!
> 
> I have investigated why StackOverflowError is thrown in AWT programs when
> Kaffe uses the interpreting engine.
> 
> Hare are my results.
> 
> 1) -ss switch doesn't affect stack size of the main thread in Kaffe. It is
> always 1M (RedHat-6.0, i686, Linux-2.2.9). However, in JDK 1.1.7v2 -ss
> affects all threads.

This is true.  Is this a problem?

My thinking was that the main stack comes more or less for free, hence
there's no need to artificially restrict it.
It has nothing to do with the problem you're pointing out, does it?

As an aside, it did lead to problems on architectures such as BeOS,
where the OS restricts the main thread's stack to 512K.
Similarly, if you "limit" your stack to anything less than 1 MB,
kaffe's stack overflow detection will fail. (See Overflow.java)
So maybe hardwiring 1MB wasn't a good choice, but I don't see that
going down to the value given by -ss is a good choice either.
After all, a lot of Java programs are single-threaded, and why not
taking advantage of the OS's stack growth mechanism for them?

> 
> 2) In the simplest case when functions are called without arguments (see
> test/regression/Overflow.java) JDK consumes 44 bytes per java call,
> Kaffe/JIT consumes 88 bytes, and Kaffe/Interpreter wastes 516 bytes!!!
> 
> 3) Alone "vmException mjbuf;" at kaffe/kaffevm/intrp/machine.c:77 consumes
> 172 bytes per java call.
> 
> AWT programs in Kaffe/Interpreter with 32k (default!) stack throw
> StackOverflowError when Java stack contains approximately 80 calls.
> Unfortunately, AWT runs in a separate thread, so this happens almost for
> all programs.
> 
> Ideas? Suggestions?
> 

Note that to my knowledge, the JDK does not keep the Java stack on the
C stack like Kaffe does, hence the separate "-oss" option.
So comparing Kaffe's native stack consumption to the JDK's native
stack consumption may not be quite fair.

Note that on the other hand, the JDK's scheme is superior in that
it makes it easier to grow the Java stack (you simply realloc it),
and it makes it a bit easier to walk it precisely.  In general, I've
been told by professional language designers, you want to keep your
native and your languages stack separate.  Especially if your threading
system doesn't grow stacks.

I don't really know how to reduce kaffe's stack consumption.
Things that come to mind are:

a) alloca mjbuf only if meth->exception_table != 0
b) reduce MAXARGS from 64 to say 16 in support.h (affects native calls)
c) don't use 64bit values for slots, use 32 bit values (ouch!)

I think only a) and maybe b) are realistic.
For now, I can only recommend you use -ss 64k or the jit (if possible).

	- Godmar