javaCalls::call and pending_exception

[Gilles Duboscq]

Yes that sounds good.
On 3 Mar 2014 22:21, "Tom Deneau" <tom.deneau at amd.com> wrote:

> Gilles --
>
> Just clarifying the use of ExternalCompilationResult.java
>
> In the original patch you gave me at the beginning of February it had
> moved into com.oracle.graal.gpu.
> In the current trunk it is in its original com.oracle.graal.api.code, but
> in that location
> it does not have the setHostGraph, getHostGraph, etc.
>
> Since I recall you saying you want to get rid of it eventually, I plan to
> leave
> it in com.oracle.graal.api.code and just add the setHostGraph,
> getHostGraph methods there.
>
> -- Tom
>
>
> > -----Original Message-----
> > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
> > Gilles Duboscq
> > Sent: Monday, March 03, 2014 5:13 AM
> > To: Deneau, Tom
> > Cc: graal-dev at openjdk.java.net
> > Subject: Re: javaCalls::call and pending_exception
> >
> > Everything should be in the openjdk graal repository.
> >
> > -Gilles
> >
> > On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau <tom.deneau at amd.com> wrote:
> > > Gilles --
> > >
> > > That's good news.  Are those HSAIL-independent changes in the trunk
> > now,
> > > or on some private branch of yours waiting to get into trunk?
> > > I confess I have not been following closely the trunk changesets
> > lately.
> > >
> > > If your HSAIL-independent changes are not in trunk yet, are your
> > changes
> > > something you can send to me and I can then merge our latest HSAIL-
> > specific changes
> > > with that and send as a webrev from that base?
> > >
> > > Otherwise I'm not clear about the contents of the webrev you are
> > asking
> > > for below.
> > >
> > > -- Tom
> > >
> > >
> > >> -----Original Message-----
> > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
> > >> Gilles Duboscq
> > >> Sent: Thursday, February 27, 2014 9:46 AM
> > >> To: Deneau, Tom
> > >> Subject: Re: javaCalls::call and pending_exception
> > >>
> > >> Hello Tom,
> > >>
> > >> I think i have most of the HSAIL independent changes that i want in.
> > >> I still would like to remove ExternalCompilationResult and the fact
> > that
> > >> HSAIL and PTX rely on installing an nmethod to execute their kernels
> > (we
> > >> would still use a nmethod for deopts but only for this purpose, not
> > for
> > >> referencing the kernels).
> > >> But i would probably rather do those changes while integrating your
> > >> changes.
> > >>
> > >> Maybe you can send me a webrev of the things you want to push and I
> > can
> > >> work with that.
> > >>
> > >> -Gilles
> > >>
> > >> On Mon, Feb 24, 2014 at 2:16 PM, Deneau, Tom <tom.deneau at amd.com>
> > wrote:
> > >> > Gilles --
> > >> >
> > >> > Status update:
> > >> >
> > >> >    * I put in the DeoptAction=Action_none workaround mentioned
> > below
> > >> and
> > >> >      confirmed that multiple depots from one kernel call all happen
> > >> correctly.
> > >> >
> > >> >    * In addition to the workitems that deopt, we can have workitems
> > >> that did
> > >> >      not run at all (we need this to limit the amount of space we
> > >> would need
> > >> >      to allocate for saving deopt information).  I have been making
> > >> changes
> > >> >      to the logic which saves the never-ran information and
> > determines
> > >> which
> > >> >      workitems did not run, but it is looking better now.
> > >> >
> > >> >    * We would like to push a webrev that adds the above level of
> > >> functionality,
> > >> >      incorporating your hsail-independent infrastructure changes
> > and
> > >> our hsail-specific changes.
> > >> >      (I've started calling your alternative compilation the
> > >> "trampoline deopt" code).
> > >> >      How should we go about this?  I'm assuming you would like to
> > >> check your infrastructure
> > >> >      changes in first.
> > >> >
> > >> > -- Tom
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Gilles Duboscq [mailto:gilwooden at gmail.com]
> > >> >> Sent: Monday, February 24, 2014 4:40 AM
> > >> >> To: Deneau, Tom
> > >> >> Cc: graal-dev at openjdk.java.net
> > >> >> Subject: Re: javaCalls::call and pending_exception
> > >> >>
> > >> >> Yes, that should work.
> > >> >>
> > >> >> On Tue, Feb 18, 2014 at 6:54 AM, Tom Deneau <tom.deneau at amd.com>
> > >> wrote:
> > >> >> > Gilles --
> > >> >> >
> > >> >> > Interesting, yes I do see the alternative method being made non-
> > >> >> reentrant after the first call.
> > >> >> > So until this gets corrected, would a workaround be for the
> > hsail
> > >> >> > side to always just use DeoptAction = Action_none?  // just
> > >> >> > interpret, do not invalidate nmethod
> > >> >> >
> > >> >> > -- Tom
> > >> >> >
> > >> >> >
> > >> >> >> -----Original Message-----
> > >> >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On
> > Behalf
> > >> >> >> Of Gilles Duboscq
> > >> >> >> Sent: Friday, February 14, 2014 9:13 AM
> > >> >> >> To: Deneau, Tom
> > >> >> >> Cc: graal-dev at openjdk.java.net
> > >> >> >> Subject: Re: javaCalls::call and pending_exception
> > >> >> >>
> > >> >> >> Hello Tom,
> > >> >> >>
> > >> >> >> One thing i did not do in the webrev I sent you is correctly
> > >> >> >> handle the code invalidation and I think this is what you are
> > >> hitting now:
> > >> >> >> - Any action that would invalidate the code needs to be re-
> > written
> > >> >> >> on one that does not invalidate the code and the code then
> > needs
> > >> >> >> to be invalidated once all workitems have been processed.
> > >> >> >> - The nmethod should never but made non-entrant externally
> > while
> > >> >> >> the kernel is running (maybe this one can be worked around just
> > by
> > >> >> >> having an offset on the entrypoint)
> > >> >> >> - The nmethod sweeper should see that this nmethod is "on the
> > >> stack"
> > >> >> >> when a thread is executing the corresponding kernel.
> > >> >> >>
> > >> >> >> I think you are seeing the 1st problem. After the first
> > >> >> >> invalidating deopt, the entry point will be patched and then
> > the
> > >> >> >> next call will land in the handle_wrong_method_stub but the
> > >> >> >> arguments and probably land in the interpreter but with
> > completely
> > >> unexpected arguments.
> > >> >> >>
> > >> >> >> -Gilles
> > >> >> >>
> > >> >> >> On Fri, Feb 14, 2014 at 4:56 AM, Tom Deneau
> > <tom.deneau at amd.com>
> > >> >> wrote:
> > >> >> >> > Gilles --
> > >> >> >> >
> > >> >> >> > Question about the special javaCalls::call we are using to
> > help
> > >> >> >> > with
> > >> >> >> deoptimization.
> > >> >> >> > We are trying to test a case where more than one workitem
> > will
> > >> >> deopt.
> > >> >> >> >
> > >> >> >> > I have a test case which basically looks like
> > >> >> >> >
> > >> >> >> >         try {
> > >> >> >> >             int index = (gid % N == 0 ? num+1 : gid);  // num
> > +
> > >> >> >> > 1
> > >> >> >> forces an arrayOutOfBounds deopt
> > >> >> >> >             outArray[index] = outval;
> > >> >> >> >         } catch (ArrayIndexOutOfBoundsException e) {
> > >> >> >> >             // do some activities in catch block
> > >> >> >> >         }
> > >> >> >> >
> > >> >> >> > So every Nth workitem will deopt.  And we catch the
> > exceptions
> > >> >> >> > in the
> > >> >> >> same method.
> > >> >> >> >
> > >> >> >> > When we run our range of workitems, we end up with several
> > >> >> >> > deopting
> > >> >> >> and several others that are unable to run because the deopt
> > save
> > >> >> >> slots have been used up.
> > >> >> >> >
> > >> >> >> > On return from the kernel dispatch, we are trying to do the
> > >> >> >> > following to handle the workitems that were unable to run:
> > >> >> >> >
> > >> >> >> >    a) for the ones that deopted, use the javaCalls::call to
> > call
> > >> >> >> > the
> > >> >> >> special alternative
> > >> >> >> >       method to help with the deopt.
> > >> >> >> >
> > >> >> >> >    b) for the ones that didn't run at all use a normal
> > >> >> >> javaCalls:call_virtual to
> > >> >> >> >       start at the beginning of the method like this
> > >> >> >> >
> > >> >> >> >       JavaCalls::call_virtual(&result, methKlass, mh->name(),
> > >> >> >> > mh->signature(), &javaArgs, THREAD);
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > As we process these workitems that didn't finish running on
> > the
> > >> >> >> > gpu, we see that all of the workitems in case a and some of
> > the
> > >> >> >> > workitems in case b will generate an
> > >> >> >> > ArrayIndexOutOfBoundsException which should
> > >> >> >> get immediately caught.
> > >> >> >> >
> > >> >> >> > For the javacalls of type b) above, we can see that all the
> > >> >> >> > workitems that generate an ArrayIndexOutOfBoundsException did
> > >> >> >> > indeed execute the
> > >> >> >> catch block.
> > >> >> >> >
> > >> >> >> > However, for the special javacalls of type a) above, only the
> > >> >> >> > first such workitem executes the catch block.  After the
> > second
> > >> >> >> > deopting workitem executes, we see the thread-
> > >> >_pending_exception is set.
> > >> >> >> >
> > >> >> >> > It seems like the type b) behavior is more correct since the
> > >> >> >> > exceptions are not really pending but are being handled in
> > the
> > >> >> >> > catch block.  Why would the two javaCalls cases behave
> > >> differently?
> > >> >> >> >
> > >> >> >> > -- Tom
> > >> >> >> >
> > >> >> >
> > >> >
> > >
>
>