graalCodeInstaller questions, recording scopes, etc.

[Doug Simon]

On Jan 7, 2014, at 11:51 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Doug --
>  
> Actually you did send this on Jan 2.  And thanks, it was a good start to getting things coded up here.
>  
> Our status as of now is:
> ·         have an c2v_installKernel0 (borrowed heavily from installCode0)
> ·         This calls a gpu function to get the backend-specific CodeInstaller derived class, then calls the install method using that installer.
> ·         For HSAIL backend, it returns an HsailCodeInstaller.  Where we have this dummy get_scope_value for now which lets us at least finish the code install.
> ScopeValue* HsailCodeInstaller::get_scope_value(oop value, int total_frame_size, GrowableArray<ScopeValue*>* objects, ScopeValue* &second, OopRecorder* oop_recorder) {
>     second = NULL;
>     return new LocationValue(Location::new_stk_loc(Location::invalid, 0));
> }
>  
> Then at runtime we can find the scope based on the PC using
>     ScopeDesc *scope = nm->scope_desc_at(pc);
>  
> And from that get the exception method and bci.   Because get_scope_value is just a skeleton, we can't yet at runtime deduce the registers or build any kind of vframe.  However, as you mentioned on the call, if the bci is 0, we can use a javaCalls call to run the kernel (we know what the kernel arguments are).
>  
> By the way, the stack corruption thing I was hunting for yesterday was caused by some not well thought out code that returned the CodeInstaller object by value.  I have reverted to returning it as a pointer and deriving CodeInstaller from CHeapObj<mtInternal>.  I don't know if that's the right way to do this, let me know if it is not.

In graalCompilerToVM.cpp the CodeInstaller is stack allocated. I’m not sure that it’s safe to do that with a CHeapObj type but maybe it’s ok. Hopefully someone more familiar with HotSpot memory allocation policies can answer this better.

-Doug