graalCodeInstaller questions, recording scopes, etc.
S. Bharadwaj Yadavalli
bharadwaj.yadavalli at oracle.com
Tue Dec 17 07:10:38 PST 2013
As I am currently implementing PTX code generation and execution using
Graal, I am also interested in participating in the call.
Please keep me posted as well.
On 12/17/2013 09:56 AM, Gilles Duboscq wrote:
> 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.
> 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
>> * 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
>> -- Tom
More information about the graal-dev