javaCalls::call and pending_exception

[Gilles Duboscq]

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