graalCodeInstaller questions, recording scopes, etc.

[Doug Simon]

On Jan 8, 2014, at 12:36 AM, Deneau, Tom <tom.deneau at amd.com> wrote:

> 
> 
>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com]
>> Sent: Tuesday, January 07, 2014 5:17 PM
>> To: Deneau, Tom
>> Cc: S. Bharadwaj Yadavalli; graal-dev at openjdk.java.net
>> Subject: Re: graalCodeInstaller questions, recording scopes, etc.
>> 
>> 
>> 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
> 
> I didn't see how it could be stack allocated if the caller didn't know the actual type of the
> CodeInstaller class (although that's what I tried first and the compiler did not warn me).
> 
> In installKernel0, I am just using it as a pointer, thus
>  CodeInstaller* installer = gpu::get_code_installer();
>  GraalEnv::CodeInstallResult result = installer->install(compiled_code_handle, cb, installed_code_handle, triggered_deoptimizations_handle);
>  delete installer;
> 
> I guess alternatively, I could have defined a
>    gpu::do_code_install(Handle& compiled_code, CodeBlob*& cb, Handle installed_code, Handle triggered_deoptimizations) 
> Then the gpu-specific code could stack allocate its own gpu-specific CodeInstaller derived object.

Yes, I think that’s the best thing to do anyway since you’re going to have to indirect through gpu to decide exactly which CodeInstaller subclass to use.

-Doug