frame deopt handling

[Doug Simon]

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