graalCodeInstaller questions, recording scopes, etc.

[Deneau, Tom]

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