graalCodeInstaller questions, recording scopes, etc.
tom.deneau at amd.com
Fri Dec 20 06:41:22 PST 2013
Closing the loop again, for my original questions, adding answers
below that were relayed in the Skype call on Thursday...
> -----Original Message-----
> From: Deneau, Tom
> Sent: Monday, December 16, 2013 3:58 PM
> To: graal-dev at openjdk.java.net
> Subject: graalCodeInstaller questions, recording scopes, etc.
> 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 or 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
Looking back we didn't really answer this question.
I know now we do need to map to some Infopoint type that does get recorded in ScopeDesc.
The AMD64 backend for DeoptimizeNode issues a InfopointReason::CALL which
is a side effect of making a Direct Foreign call.
On the HSAIL side, we are not really making a foreign call and I am unsure of the
full semantics of the other types. As an experiment I tried InfopointReason.IMPLICIT_EXCEPTION
which does get recorded in the ScopeDesc thru site_Safepoint.
But again, not sure if that is the recommendation.
> * 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 issue will be handled by the virtualization of some of the calls
in graalCodeInstaller that Doug will be implementing.
> -- Tom
More information about the graal-dev