Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rdasgupt@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=q0xXqYisZZ/e80ppk36vEEQZOF7mSyUlbZfVB+RUHiAhbdUslzLBmiM49S/RaxNU+DZUtL4xeheXyedpYiJwPER3ILKCDg3j8QSJ03qDuUvo+Oq34qW9Hb608ux8h9f7GNlXnivK66fQbtyS6QzocXLx1h9kvst9dSzmUzzfVYs=
Message-ID: <51d555c70607241200p43fee118m6446a96197ea561a@mail.gmail.com>
Date: Mon, 24 Jul 2006 12:00:30 -0700
From: "Rana Dasgupta" <rdasgupt@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Stack Overflow Error support issues
In-Reply-To: <bc79dd600607240507k2e5f1f04y7cc35c67efab0259@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8062_20494563.1153767630833"
References: <783bf8b0606221051g557ac491xc55244d9f770457d@mail.gmail.com>
	 <bc79dd600606280537n50e715e1ye2fe22b58b70eb93@mail.gmail.com>
	 <4dd1f3f00606280654n4e9cde5fgf7f4bedd5dd75042@mail.gmail.com>
	 <783bf8b0606280713nf5d5567pe26f60aae933e3d5@mail.gmail.com>
	 <51d555c70606291437x497da2fbr715ae49253b88717@mail.gmail.com>
	 <783bf8b0607210433i52c7074fhcde6c65dc07da677@mail.gmail.com>
	 <51d555c70607211241w2b313d77ob7af984560fd5d56@mail.gmail.com>
	 <bc79dd600607211448n491024ecl7234237702c82cea@mail.gmail.com>
	 <783bf8b0607240314v6f1ea511x4217773e0cb185a0@mail.gmail.com>
	 <bc79dd600607240507k2e5f1f04y7cc35c67efab0259@mail.gmail.com>

------=_Part_8062_20494563.1153767630833
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_8062_20494563.1153767630833--