javaCalls::call and pending_exception

[Deneau, Tom]

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