harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Wed, 28 Jun 2006 13:54:01 GMT
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 <mike.fursov@gmail.com> wrote:
> On 6/23/06, Pavel Afremov <pavel.n.afremov@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message