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.
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? 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. On 6/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 6/23/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: > > .. > Pavel, I think SOE in native code should be avoided. AFAIK internal JIT algorithms use recursion a lot and for a huge control flow graph stack size could be not enough to compile a method. The one option I see is every native component is to be responsible to report an error before SOE happened and not to crash the program. So, if DRLVM would have a public method like 'get_available_stack_size' a component could check it and call to VM helper with failure notification or run some recovery code in case the stack size is too small to complete the compilation. As an example I can propose introducing the recovery mode for JIT compilers: to add the Jitrino.JET (lightweight compiler) as the last JIT in execution manager (EM) configuration. If Jitrino.OPT or any other optimizing JIT fails to compile a method due to the huge method size, it just returns failure to the Execution Manager (EM) and EM can silently ask the next JIT in the configuration to compile the method. The last attempt to compile will be on the Jitrino.JET which requires significantly less resources then other JITs and will compile a method without SOE. Does anyone have other ideas how to handle SOE in native code? -- Mikhail Fursov
-- Weldon Washburn 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]
