harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Thu, 29 Jun 2006 21:37:06 GMT
On 6/28/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> >The first is used in the second to make required check and the second
> used
> >to check, that there are 256 Kbytes of free stack, before starting
> >compilation.
> >So I can add both this functions into open interface and put a patch into
> >JIRA.
> >Will this solution be OK for all components?

I would delay putting something like this into Open:

   -  This is a part of a specific implementation of some kind of
   a reliability contract that we could choose to  offer through the  DRLVM +
   associated jits +  verifier, but it is not clear why everyone else would
   like to implement such a contract in an identical way, or would be
   interested in offering such a contract.
   - While delegating to a downlevel jit( as Mikhail mentions )is quite
   elegant, it is an advantage we ( DRLVM ) have because we have such a jit,
   all components may simply not be able to recover from a SOE error.
   - It also seems to me that even proactive checking cannot guarantee
   that an unchecked SOE will not happen anywhere in a large program and that
   the OS will not tear down the process. Or if it can, we don't know how
   expensive it is to make this check everywhere in a large program.
   - It is possible to think/imagine  attributing some classes as
   "reliable" ....as a declarative contract between the app and the JVM where,
   provided the java developer does some sensible things , the jit,
   verifier etc. could make sure that such failures cannot occur, by eg.,
   making these proactive checks etc.

>2. If StackOverflowError is thrown during the first two commands of
>  >compiled method, function "unwind "of the JIT cannot always unwind frame
>  >correctly.
> >What do you think about this issue?

This looks lile a bug. I can try to repro it unless we have a solution



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