harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Wed, 28 Jun 2006 14:30:18 GMT
You can see my comments inline.

On 6/28/06, Weldon Washburn <weldonwjw@gmail.com> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message