graalCodeInstaller questions, recording scopes, etc.

[Gilles Duboscq]

Hi,

This is a lot of questions that are not simple to answers.
I think we should talk about this on skype so that we can converge more
quickly on a clearer picture on both sides.
Doug an I have time on Thursday (2013-12-19) around 19:00 CET (10 am PST)
would this work for you?
Doug's skype username is dougxc, mine is gilwooden.

-Gilles


On Mon, Dec 16, 2013 at 10:57 PM, Tom Deneau <tom.deneau at amd.com> wrote:

> Wanted to run a sketch of our plans by the rest of the graal team and
> get some advice...
>
> When there are situations we cannot handle on the HSAIL backend, we
> want to deoptimize and handle them in the interpreter.  Our thoughts
> were that at codeInstall time, we could record the various infopoints
> in the compilationResult and then the graalCodeInstaller would then
> record these in some way in the nmethod or in some structure that we
> could access at runtime.  Then at runtime, if a workitem requests a
> deopt, it would save its HSAIL state, including all the appropriate
> HSAIL registers in a place that the host side could access.
>
> If the JVM code that invokes the kernel sees that one or more
> workitems have requested a deopt, for each one we could
>
>    * map the HSAIL "PC" back to the appropriate infopoint
>
>    * use the infopoint and the saved HSAIL registers to construct the,
>      host-based interpreter frames
>
>    * and then let things continue in the interpreter.
>
> Some questions:
>
>    * What reason should we use for the InfopointReason?  In
>      graalCodeInstaller.cpp, it seems that some types get "recorded"
>      in the debug_recorder via site_Safepoint of site_Call, while
>      others like InfopointReason::LINE_NUMBER do not.  I am assuming
>      we should "record" ours but am not sure how this all plays
>      together.  Can we map back to an infopoint that has not been
>      recorded?
>
>    * Our infopoints have byteCodePositions.  The ones that get
>      "recorded" go thru record_scope which has all sorts of
>      host-specific checking on the scope info.  For instance,
>      get_hotspot_value will compare a register # with
>      RegisterImpl::number_of_registers (which refers to the host) and
>      if it is, assert that the type is FLOAT or DOUBLE.  None of this
>      holds with HSAIL registers.  What is the best way to resolve
>      this?
>
> -- Tom
>
>
>