A hotspot patch for stack profiling (frame pointer)

[John Rose]

On Jan 14, 2015, at 6:42 AM, Bertrand Delsart <bertrand.delsart at oracle.com> wrote:
> 
> I would not prevent the JITs from using RBP as long as the changeset is not sufficient to guarantee the profiling will work... and IMHO solving the JSR292 issue will be much more intrusive (impacting HotSpot stack walking code).

Here are some thoughts on that.

SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle support as x86 uses RBP (rbp_mh_SP_save).  So there's not a hard requirement for x86 to take over RBP.

(Deep background:  This purpose, in method handle support, is to allow an adapter to make changes to the caller's SP.  The adapter is the initial callee from the caller, but may change argument shape, and tail-calls the ultimate callee.  Because it is a tail-call, the original caller must have a spot where his original SP can be preserved.  The preservation works because the original caller knows he is calling a MH.invoke method, which requires the extra argument preservation.  The repertoire of argument shape changes is quite small, actually; it is not a very general mechanism since the LF machinery was put in.  Perhaps the whole thing could be removed somehow, by finding alternative techniques for the few remaining changes.  OTOH, this SP-restoring mechanism may be helpful in doing more a general tail-call mechanism, and perhaps in managing int/comp mode changes more cleanly, so I'd like us to keep it.  And document it better.)

Any register or stack slot will do for this purpose, as long as (i) its value can be recovered after the MH.invoke call returns to the caller, and (ii) its value can be dug up somehow during stack walking.  There are only a couple of places where stack walking code needs to sample the value, so they should be adjustable.

Both x86 and SPARC use registers which are callee-save (or "non-volatile across calls") which satisfy properties (i) and (ii).  A standard stack slot (addressed based on caller's RBP) would probably also satisfy those properties.

A variably-positioned stack slot would also work, which would require registering the position in each CodeBlob.  That's unpleasant extra detail, but it would align somewhat with the current logic which allows each CodeBlob (nmethod, actually) to advertise which call sites need the special processing (see the function is_method_handle_return(caller_pc)).

I recommend reserving a dead word of space in every stack frame that makes MH.invoke calls, at a fixed position relative to that frame's RBP.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150114/0f15a51a/attachment.html>