harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Tue, 25 Jul 2006 06:59:55 GMT
Guys,

I'm just curious - anybody know how probable is the chance to hit
stack overflow during compilation vs managed code execution and vs
native code execution?
Shouldn't we care (even more) about kernel/classlib natives? I guess
there are enough places lacking guard checks like " if
(ExceptionOccured()) return 0;"

BTW, the SOE machinery seems to be incomplete for this case, see
HARMONY-971 issue.

--
Alexey Varlamov

2006/7/25, Rana Dasgupta <rdasgupt@gmail.com>:
> As I understand it, the value added by a broad check like this before the
> compile starts may not be very high. At best, it can try to avoid SOE in
> native code with a clean failure when it is certain that the stack state
> will not permit completion of the compile. So something like 1/100 of the
> stack as Mikhail mentions sounds reasonable, and the VM could do this. This
> is something like a tuning activity and some experiments may also help.
>
> It is also true that to offer real guarantees that overflow will not occur,
> the JIT will need to consider this bound before making optimization
> decisions or to limit recursion depth in algo selection. But this is a lot
> to do proactively in the Jit, just to try to avoid SOE. My suggestion is
> that we can consider doing these defensive checks in the Jit only if we want
> to offer and honor some published reliability guarantees. This is a broader
> topic and would need to include not only SOE, but several other failures
> like ThreadAbort etc. that the user does not usually anticipate and are not
> user code failures. Basically these are guarantees that if the user follows
> some reasonable guidelines, certain portions of his code cannot fail. How
> those guarantees can be exposed etc. ( eg., a method attributed with an
> attribute "Reliable" that the Jit and VM support, or some command line flags
> etc. ) is  a matter of design. We should defer this work unless SOE becomes
> an issue with our apps of choice or this type of "reliable managed code" is
> a design requirement in Harmony.
>
> For now, it may be better to periodically check for the exception state on
> the thread in line with Pavel's original design.
>
> Thanks,
> Rana
>
>
>
>
> On 7/24/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >
> > No, I think that VM can do this check but use lower border: e.g. 1/100 of
> > initial.
> > JIT must do this check more accurate: use knowledge of algorithms it uses.
> >
> > The requirement to avoid SOE during a compilation can affect any algorithm
> > in JIT that uses recursion. Jitrino.OPT has a lot of such algorithms:
> > node,
> > insts, opnd based . So I'm not sure that JIT can construct a heuristic or
> > a
> > profile to refuse to compile a method in the beginning of the compilation.
> > The another option is to check available stack size before any recursion
> > based algorithm and limit the algorithm up to N steps in recursion (N is
> > recomputed in runtime) . If N steps is not enough algorithm will fail and
> > JIT will not not perform the optimization or compilation at all.
> > Quite a lot of changes in JIT though. Any other ideas?
> >
> >
> >
> >
> > On 7/24/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> > >
> > > Hi
> > >
> > > On 7/22/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >
> > > > I think this must be a JIT heuristics because even a small method can
> > > lead
> > > > to inlining of whole classlib API :)
> > >
> > >
> > > Are You think this check should be removed from VM and puted into JIT
> > > only?
> > >
> > > BR
> > > Pavel Afremov.
> > >
> > >
> >
> >
> > --
> > Mikhail Fursov
> >
> >
>
>

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


Mime
View raw message