actions -- Rebuilding the Interpreter Frames on the GPU

[Deneau, Tom]

Gilles --

By Thursday this week we should be able to give you a webrev that can be applied to trunk
that you can look at or even build and run on the simulator.  At runtime of course it only
goes as far as retrieving the values from the HSAIL Frame and displaying them.

Meanwhile if you want to look at something before that I have put a directory at

http://cr.openjdk.java.net/~tdeneau/graal-webrevs/gpu_hsail_debuginfo_files/ 

which contains the current state of the classes you asked about below.

Notes:
   * In HsailCodeInstaller::get_scope_value, you can see we only have support for register values
     for now, and we just save the HSAIL global register number in the ScopeDesc.

   * The HSAILLocation class is used to decode that saved Location value at runtime

   * and the HSAILFrame class is used to retrieve a value from the frame saved by deopting workitems.

-- Tom


> -----Original Message-----
> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
> Gilles Duboscq
> Sent: Wednesday, January 15, 2014 4:38 AM
> To: Deneau, Tom
> Cc: Doug Simon; graal-dev at openjdk.java.net
> Subject: Re: actions -- Rebuilding the Interpreter Frames on the GPU
> 
> Hello Tom,
> 
> It's on my list, i already had a closer look at the frame rebuilding
> code.
> I would be interested to have a look at the code of your CodeInstaller
> subclass and the code you use to retrieve the runtime values so that i
> can experiment with it.
> 
> -Gilles
> 
> On Mon, Jan 13, 2014 at 5:09 PM, Tom Deneau <tom.deneau at amd.com> wrote:
> > Gilles, Doug --
> >
> > A status update on our end...
> >
> >    * We now generate HSAIL code to save the register state at deopt
> > points
> >
> >    * We have an HSAIL-specific CodeInstaller class based on the
> changes
> >      Doug added and we use this at compile time (code-install time) to
> >      build the ScopeDescs.  (This avoids the host-register specific
> code
> >      in the base CodeInstaller class).
> >
> >    * At runtime, if we detect that a workitem deopted, we map the
> saved "HSAIL pc"
> >      to the relevant ScopeDesc and use each Location item in the
> ScopeDesc
> >      to retrieve the relevant HSAIL register from the HSAIL frame
> (where the
> >      registers were saved).
> >
> > Right now we just print out the live locals or expression stack values
> > for the deopted workitem and they look correct.  The next step would
> > be to rebuild the interpreter frames.
> >
> > Can I get an update on the "C++ changes needed to easily rebuild the
> > interpreter frames from a raw buffer provided by the GPU".
> >
> > -- Tom
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-
> >> bounces at openjdk.java.net] On Behalf Of Gilles Duboscq
> >> Sent: Friday, December 20, 2013 4:31 AM
> >> To: Doug Simon
> >> Cc: graal-dev at openjdk.java.net
> >> Subject: Re: actions
> >>
> >> As for me, I'll look into the C++ changes needed to easily rebuild
> >> the interpreter frames from a raw buffer provided by the GPU during
> >> deoptimization.
> >>
> >> -Gilles
> >>
> >>
> >> On Thu, Dec 19, 2013 at 11:27 PM, Doug Simon <doug.simon at oracle.com>
> >> wrote:
> >>
> >> > As a result of the Sumatra Skype meeting today on the topic of how
> >> > to handle deopt for HSAIL & PTX, I’ve signed up to investigate
> >> > changes in the
> >> > C++ layer of Graal to accommodate installing code whose debug info
> >> > C++ is not
> >> > in terms of host machine state (e.g. uses a different register set
> >> > than the host register set).
> >> >
> >> > -Doug
> >> >
> >> > On Dec 19, 2013, at 11:02 PM, Deneau, Tom <tom.deneau at amd.com>
> wrote:
> >> >
> >> > > Gilles, Doug --
> >> > >
> >> > > Could you post to the graal-dev list what the two action items
> >> > > you took
> >> > were?
> >> > >
> >> > > -- Tom
> >> >
> >> >
> >