harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Wed, 28 Jun 2006 21:45:02 GMT
Weldon, as far as I understand. There is no problem with jitted code
stack overflow checks. The problem arise for JIT compiler itself. It
can consume large amount of memory during optimizations. We should be
able to handle stack overflow in this native code.

The problem I see is that we don't know for sure the layout of code
generated by C compiler (the code of JIT compiler or verifier). It can
be quite different for different C compilers or level of optimization.
IMHO, we cannot guarantee that particular code will feet in the
specified amount of memory, it can be only rough approximations. This
problem can be easily fixed when/if we will move to pure-java JVM.

On 6/28/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 6/28/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> > You can see my comments inline.

> > I think it's impossible to find max amount of stack that is required for
> > complex components, like JIT. But it's possible to put constraints for some
> > functions, which does simple compilation tasks.
> hmmm... you may be right.  But I still think its worth asking the
> question anyway.  Some observations.  It might be possible to build a
> simple JIT that emits code and forward branch patch locations in one
> pass.  The jit would do a "malloc()" for the code and patch records
> thus conserving the stack.  A second pass would fixup the branch
> patches. Given the constraints on *.class structure, it might be
> possible to do a limit study on how big the JIT data structs could
> become.  For example, the class file contains a struct called,
> "Code_attribute".   This struct contains start_pc and end_pc that are
> 16-bit integers which point into the bytecode.  Does this limit the
> size of the bytecode array to 64KB?  max_locals and max_stack are
> limited to 64K.  It is understood that even if a limit study could  be
> done on max jit hardware stack, the size might still be too big for a
> practical JVM.  In any case, it would be nice to know.

Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message