frame deopt handling

[Doug Simon]

On Jan 8, 2014, at 6:14 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> I just didn't know if anyone else relied on these Location fields for anything.
> 
> Does this mean we can use any convention for the Location fields of the ScopeDesc that we wish, as long as we are internally consistent?

Yes (although there may be some generic ScopeDesc printing code that has host-based assumptions).

-Doug

>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com]
>> Sent: Wednesday, January 08, 2014 10:08 AM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: frame deopt handling
>> 
>> 
>> On Jan 8, 2014, at 3:17 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>> 
>>> Graal Hotspot gurus --
>>> 
>>> I am having trouble finding my way around the frame deoptimization
>> code.  I see where locations are set up for the various locals,
>> expressions, etc. in the ScopeDescs thru our CodeInstaller interfaces
>> but where are those location indicators then read at runtime?
>> 
>> You don't need to look at where the normal ScopeDescs are read at
>> runtime because the GPU ScopeDescs will not be processed there. Instead,
>> they will be processed at the site where a GPU compiled method returns
>> with a result code denoting a deopt occurred and all the deopt values
>> stored in a buffer. From an earlier mail:
>> 
>> "What you need is for deoptimization to record in a buffer all the
>> values described by a ScopeDesc that will be accessible to the subsystem
>> that inspects the deoptimization state (ie. where the ScopeDesc is
>> used). Deopt points in host compiled code will either be safepoints
>> (e.g. AMD64HotSpotSafepoint) or calls. On HSAIL, you need to expand on
>> the concept implemented in Eric's webrev[1] where code explicitly stores
>> state to a memory block (i.e. %_deoptInfo). This state will be at least
>> the HSAIL register values. I don't know what memory is used for the
>> stack in HSAIL, but if it is not accessible by the host or will not be
>> live when the host needs to access the debug info, then the values on
>> the stack also need to be written to the deopt info block."
>> 
>>> In a similar vein, a routine like frame::local_offset_for_compiler, I
>> didn't see any place that was actually called from?
>> 
>> Just do a global search for "local_offset_for_compiler" in Eclipse and
>> you find a call from frame::monitor_offset_for_compiler in
>> frame_x86.inline.hpp
>> 
>> -Doug
> 
>