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 Wed, 26 Jul 2006 06:40:25 GMT
On 7/25/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 7/25/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> >> Hello
> >>
> >>
> >>
> >> I can't reproduce assertion described in HARMONY-971, but it possible
> > >indeed. Alexey is right, lazy exception support for VM code fixes this
> and
> > >other similar bugs.
> >I think I understand the above.  Lazy exceptions only actually create
> >the exception object if an  exception handler can be located that
> >actually consumes this object.  If an exception handler is located and
> >it does not use this object, the optimization is to never create the
> >exception object.
> >The net result is that an exception can indeed be properly thown when
> >there is zero memory to allocate any new object.  This, in turn,
> >improves DRLVM's overall stability and ability to deal with Stack
> >Overflow Exceptions correctly.  In other words, it reduces the
> symptoms which is good.  But it does not completely solve SOE
> >problems.

Not sure I understand. Lazy exception handling is an efficiency
optimization, not a correctness enhancement. As Weldon says, there *could *be
some indirect benefits and relief of memory pressure in that the
exception is not created unless the exception object is live at entry to a
matching handler. But if it matches, it still needs to be created ...and it
does not address the problem that certain prolonged sections of the
jit/verifier code are unwindable.

> >> The other possible solution is check available stack size before
> running the
> >> VM functions which should works in suspended mode and which can be
> source of
> > >stack overflow.
> >I don't know what "suspended mode" is.  Please explain.

  I didn't understand this either!

> >>
> >>
> >> The third solution is using pre created exception like for
> >> OutOfMemoryException.
> >>
> >>
> Do you mean all exception objects or just SOE? This has implications on
> Java semantics. The exception objects need to be created in the right
> context with all associated side-effects.
> --
> 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

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