graalCodeInstaller questions, recording scopes, etc.

[Deneau, Tom]

> -----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.