javaCalls::call and pending_exception

[Deneau, Tom]

Actually I noticed when I put it back in com.oracle.graal.api.code and added a dependency in mx/projects on com.oracle.graal.nodes, there was then a cycle in the dependencies.  So I put it back in com.oracle.graal.gpu for now.

-- Tom

From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Monday, March 03, 2014 3:39 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: RE: javaCalls::call and pending_exception


Yes that sounds good.
On 3 Mar 2014 22:21, "Tom Deneau" <tom.deneau at amd.com<mailto: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> [mailto: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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto:gilwooden at gmail.com>]
> >> >> Sent: Monday, February 24, 2014 4:40 AM
> >> >> To: Deneau, Tom
> >> >> Cc: graal-dev at openjdk.java.net<mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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
> >> >> >> >
> >> >> >
> >> >
> >