javaCalls::call and pending_exception

[Gilles Duboscq]

Everything should be in the openjdk graal repository.

-Gilles

On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau <tom.deneau at amd.com> wrote:
> 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
>> >> >> >
>> >> >
>> >
>