javaCalls::call and pending_exception

[Deneau, Tom]

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