graalCodeInstaller questions, recording scopes, etc.
tom.deneau at amd.com
Mon Dec 16 13:57:45 PST 2013
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.
* 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
* 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
More information about the graal-dev