javaCalls::call and pending_exception

[Deneau, Tom]

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