estimate

[Deneau, Tom]

Gilles --

Yes, I believe we would eventually like to push a webrev encompassing what we have in the area of deoptimization support.  I agree there is a lot of cleaning up to do both in the hsail side and the gpu-target-independent side.

I thought the steps would be:
   1) You or someone at Oracle does a checkin to trunk that encompasses only the gpu-target-independent part.
      At that point, the interfaces would be defined but nothing would be using them  yet.

   2) Following that, AMD proposes a webrev for the hsail part that uses the new interfaces plus includes
      all the other deoptimization related hsail code (that has never been checked in yet).

-- Tom


> -----Original Message-----
> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
> Gilles Duboscq
> Sent: Tuesday, February 11, 2014 5:18 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: estimate
> 
> Tom,
> 
> This experiment, as well as what is foreseen for PTX, seem to indicate
> that we don't need a nmethod for the GPU kernels themselves.
> The kernel in turn may need to know about a special nmethod which is
> used for example to implement deoptimization.
> 
> This special nmethod needs to 'interface' with the VM because it
> potentially has an unexpected signature (i.e. its signature is not the
> signature of the method it pretends to be). For this i would propose
> to have long pointer to a "custom c2i" in HotSpotNMethod or in a new
> subclass of HotSpotNMethod. This would be picked up automatically by
> JavaCall when using our "alternative nmethod" mechanism.
> 
> An other thing I'm not yet sure about is if we need the
> ExternalCompilationResult at all. I currently transmit the "host
> graph" (which is built during HSAIL compilation) through it but maybe
> there is a better solution.
> 
> Regarding coordination, I don't know if/when you want to push the
> changes for deoptimization support. If you want to push them, we
> should prepare a webrev which combines your work and what I did.
> 
> -Gilles
> 
> On Mon, Feb 10, 2014 at 5:10 PM, Tom Deneau <tom.deneau at amd.com> wrote:
> > Gilles --
> >
> > This is working well for us and it also passes tests on some early HSA
> hardware we have.
> >
> > Let me know what kind of coordination you refer to below.
> > I guess there's not yet quite a clean line between the hsail-dependent
> part and the hsail-independent part.
> > Maybe you can send a proposal on what you would like for such an
> interface.
> >
> > -- Tom
> >
> >> -----Original Message-----
> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
> >> Gilles Duboscq
> >> Sent: Friday, February 07, 2014 5:13 AM
> >> To: Deneau, Tom
> >> Cc: graal-dev at openjdk.java.net
> >> Subject: Re: estimate
> >>
> >> After some debugging, it now passes all the HSAIL unit tests.
> >>
> >> I attach a diff, it's based on your patch (v4 if i remember
> correctly)
> >> itself applied on graal a9604b40f5e7.
> >>
> >> This diff contains a number of changes to HotSpot and Graal outside
> the
> >> strict context of HSAIL which were necessary to make this work.
> >> Going forward, I'll first integrate those changes (the ones that are
> not
> >> strictly HSAIL) into our repo but then we need to coordinate to
> polish
> >> and push both your and my changes.
> >>
> >> I think we should remove the hsail-deopt-info support
> >> (HSAILCodeInstaller and HSAILLocation) since it is not needed any
> more.
> >>
> >> -Gilles
> >>
> >> On Fri, Feb 7, 2014 at 10:29 AM, Gilles Duboscq <duboscq at ssw.jku.at>
> >> wrote:
> >> > Hello Tom,
> >> >
> >> > I now have code for the whole depot path. I am now in the process
> of
> >> > debugging the access to the HSAILFrame from the host code (some of
> the
> >> > indices I'm using seem to be off).
> >> > For now, besides some indices problem, the host code looks correct
> and
> >> > I can get HotSpot to execute it when there is a hsail deopt. Also
> >> > HotSpot can walk the stack properly when the host code triggers the
> >> > actual deopt and it sees the correct VM->Java transitions.
> >> >
> >> > The changes should simplify the code a bit since I don't need the
> >> > special code installer or anything around that. All debug info are
> now
> >> > host debug info.
> >> >
> >> > I'm hoping that debugging will work out today but in any case I
> will
> >> > send you a patch today. Hopefully it should pass at least some of
> the
> >> unit tests.
> >> >
> >> > -Gilles
> >> >
> >> > On 6 Feb 2014 21:38, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> >> >>
> >> >> Hi Gilles --
> >> >>
> >> >>
> >> >>
> >> >> Again to help with our internal planning, can you give us a rough
> >> >> estimate of how far away the gpu-deopt-to-interpreter
> infrastructure
> >> might be?
> >> >>
> >> >>
> >> >>
> >> >> And is there anything we can do on our side to prepare for it?
> >> >>
> >> >>
> >> >>
> >> >> -- Tom
> >> >>
> >> >>