javaCalls::call and pending_exception

[Gilles Duboscq]

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
>