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 Tue, 25 Jul 2006 15:26:27 GMT
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.  The question I think is important to find out is if the
above is good enough for 2006 goals.

> 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.

> The third solution is using pre created exception like for
> OutOfMemoryException.
> I think that the first solution is the best.

Lazy object creation also has an added benefit of reducing the amount
of time it takes to throw an exception (which is good).  A question
about the third solution.  Will it be a better solution when an
exception handler does indeed consume the exception object?  In other
words, does the third solution fix more SOE corner cases than the
first solution?

> So I'd like start experiments with lazy exceptions support for VM code.

The last time I looked, the lazy exception code was still in DRLVM
code base.  The experiments would be to find out if it causes more SOE
cases to be handled correctly?  Is this right?

> Thanks.
> Pavel Afremov.

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

View raw message