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, 26 Jul 2006 15:25:32 GMT
On 7/26/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> Hi
> The main issue  is that new object can't be created in suspend disabled
> mode. DRL VM is in this state during "GC unsafe" operation, when GC have not
> been started. New SOE can't be created in this mode. But all information
> about exception can be stored in thread local storage. When Vm return
> control to managed code, function rethrow_current_thread_exception is
> called, and this function can decide to create exception (it's possible
> here) or throw it lazy.
> Now "lazy exception" supported for MANAGED code only, Alexey propose extend
> it for VM code. This technique should fix the most case when exception
> should be raised in suspend disabled mode.

Aha!  I think I now understand what you are suggesting.  You propose
to borrow the technique of lazy exception throw.  A better term might
be "deferred exception object creation".  DEOC happens to use the same
mechanism as lazy exception throwing.  The idea is to defer the
creation of the exception object until the JVM is in a state where it
can actually create the desired object.  If this is what you intend, I
like it.  And I can see how it could address situations where the JVM
is in a state such that object creation could lead to a deadlocked GC.

Looking at the top-level for a minute, guaranteeing that the JIT will
gracefully throw a Stack Overflow Exception instead of crashing might
require rewriting a bunch the JIT with this new requirement in mind.
Then testing the recursion code paths for compliance.  While this
could be done, my guess is that this might be very disruptive to the
existing harmonydrlvm code base.  Before embarking on such a project,
I would like to see evidence that workloads Harmony cares about push
the JIT into situations that expose SOE problems.  I suspect there are
other higher value things we should be doing like getting more
commercial workloads up and running.

Stack Overflow Exception handling needs to be good enough for
commercial workloads.  This might be less than required for absolute
correctness.  The approach I would take at this time is to make stack
size and guard page size adjustable at the command line.  Then when we
suspect a stack overflow problem, bump up the stack and guard page
sizes substantially.  If the problem disappears, we might have an
interesting SOE case to study (and to guide what a reasonable JVM
should do.)  Otherwise, we are designing for the absolute worst case.
While this is ideal, it might not be required and could lead to all
sorts of other problems like unmaintainable code...

> About "suspended" mode. It's misprint for suspend disabled mode. Sorry for
> confusion. The issue is in check available stack size before entering in
> suspend disabled mode, and raise new SOE if available stack size is not
> enough.
> The third point is not really fix. I think it's workaround for cases when VM
> can't create new exception object by different reasons. I suppose, VM can
> raise pre created SOE  in the case when stack overflow happen in suspend
> disabled mode and stack can't be unwound destructively.
> 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