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. -- Ivan On 6/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 6/28/06, Pavel Afremov <[EMAIL PROTECTED]> 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.
-- Ivan Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
