You can see my comments inline. On 6/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Some comments and observations: 1) I like Pavel's approach of trying jitrino.JET. Is it possible to put constraints on the max amount of hardware stack that JET uses? Is it possible to calculate the max amount of stack that JET could use? If these numbers are knowable, it could help in the design.
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. 2)
Stack overflow in the VM is very much analogous to what I remember from old Linux/Windows kernels. A kernel stack overflow causes a crash. Thus the kernel is specifically designed to avoid kernel stack overflow. Other than the jit, are there other places in the VM that do deep recursion? If true, where are they and can they be redesigned to not abuse the stack?
The other known for me component is verifier. I think it can be redesigned to add SOE support. But I'm not sure on 100% now. Can anybody investigate it? 3)
One approach might be to put the JIT in a separate "vm thread" that never executes any code other than the JIT. Thus the only frames on the stack are due to the JIT itself. This might make recovery after overflow simpler. For example, let the JIT hit the guard page at the top of its stack and throw a hardware exception. The exception would be caught by the JVM itself -- no Java execption would ever be involved. Cleanup would involve free()'ing the stuff the jit malloc()'ed, unwinding JVM locks the JIT held, closing files, releasing class loader resources, etc. Once the cleanup is done, return an error to Java code and let the java code run its course.
It's interesting idea. BR Pavel Afremov.
