Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of weldonwjw@gmail.com designates
 64.233.182.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=piiCNQ0NYJVyrBoBnrDu5hNb3EQVSWsn4AB8yzPEG78RXaYTFfVoC1VsN7LH/FY8C6wVLt5yeImZQuhf8jhks9iMgSQ3RTP0wNanm4bxtVQR3pYhJkARX1ABupWO2PT9sS+zqu69ZHCLzH7Vd0lf+c6IbYCuuDf0e/rxV2zwmXI=
Message-ID: <4dd1f3f00703122204r617d8c21h34da316b6353f8e4@mail.gmail.com>
Date: Mon, 12 Mar 2007 22:04:15 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][threading] H3010 (Stack Overflow Exception) -- when does
 this bug really have to be fixed?
In-Reply-To: <51d555c70703121758l4b30db1dk7f67c66170376b5e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9526_29550167.1173762255487"
References: <4dd1f3f00703120905q3651b5e8g33dda1a687b9b5cc@mail.gmail.com>
	 <51d555c70703121758l4b30db1dk7f67c66170376b5e@mail.gmail.com>

------=_Part_9526_29550167.1173762255487
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/12/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Weldon,
> It would be nice if exceptions in the fast native helper code paths could
> be
> treated as exceptions in unwindable ( jitted ) code.
> Though the test case is artificial, I think that this is a valid bug and
> could show up under stress. We could fail fast for now ( assert zero ) as
> you suggest and defer it till the fast path is written in java.


hmm... interesting concept.  It might actually be easier/better for the JIT
to solve this problem.   Simply as the JIT to treat this code as it would
any other JIT emitted code.  We need to have a Harmony discussion with the
JIT developers on this one.  I will add a comment to the JIRA.

Thanks,
> Rana
>
>
> On 3/12/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> >
> > All,
> > I assigned H3010 to myself.  This test definitely demonstrates a bug
> that
> > needs fixing.  But its not clear when this bug must be fixed.  This
> really
> > brings forward a higher-level.  What to code this bug right now and when
> > would this bug be moved to "blocker" status?  I provide some
> observations
> > to
> > start the discussion:
> >
> > 1)
> > The bug is a Stack Overflow Exception happens from inside fast native
> > helper
> > functions.  Fast native helpers do not setup the M2N stack frame which
> is
> > required to throw exceptions such as SOE.  Adding M2N setup to fast
> native
> > helper will unacceptably slow down the system.
> >
> > 2)
> > When running useful workload, a Stack Overflow that hits precisely on a
> > fast
> > native has a very low probability.  Note the test in H3010 specifically
> > forces this event to happen with a very high probability.  In other
> words,
> > while the test is a good, it reflects a very rare event in nature.
> >
> > Given the above, how about we address fixing the problem in two stages:
> >
> > 1)
> > First stage: add an "assert(zero);" to the exception handler when it is
> > determined an SOE has happened inside a fast native.  This way, we will
> > find
> > out quickly when an important workload hits this bug.  Once the
> > assert(zero)
> > is added, we code H3010 as "later"
> >
> > 2)
> > Second stage: When an application we care about hits the assert(zero),
> we
> > recode H3010 as "major/blocker".
> >
> > 3)
> > While waiting for #2 above to happen, we discuss on harmony-dev ways of
> > designing the right fix.  For starts,  I think we should investigate a
> > design where the exception handler rewrites the entire register context
> so
> > that returning from exception handler revectors the instruction pointer
> to
> > recovery code that will somehow push the M2N frame on the stack and call
> > proper SOE throwing code.  I have not looked closely at how to do
> this.  I
> > am not convinced this approach will work.  However, I do think its worth
> a
> > try.  Thoughts?
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

------=_Part_9526_29550167.1173762255487--