graalCodeInstaller questions, recording scopes, etc.

[S. Bharadwaj Yadavalli]

Hi,

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.

Regards,

Bharadwaj

On 12/17/2013 09:56 AM, Gilles Duboscq wrote:
> 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
>>
>>
>>