A hotspot patch for stack profiling (frame pointer)

[serguei.spitsyn at oracle.com]

On 1/15/15 3:13 AM, Bertrand Delsart wrote:
> On 14/01/2015 20:12, John Rose wrote:
>> On Jan 14, 2015, at 6:42 AM, Bertrand Delsart
>> <bertrand.delsart at oracle.com <mailto: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
>
> I perfectly agree that it is doable (and with your proposed approach).
>
> I just wanted to be sure people were aware that the RFE is more 
> complex than what the current changeset may suggest. We are not just 
> taking about reviewing and integrating a complete changeset 
> contributed by the community. There is more work needed, either by the 
> community or by Oracle. This will require changes at least in C1 and 
> C2 call sequences, in the stack walking, in the creation and sizing of 
> compiled frames...

Just want to note about the stack walking...
It also impacts some places that people are normally unaware of:
  - SA-based stack walking (jstack utility)
  - Solaris-specific: jhelper.d (dtrace jstack action support) and 
libjvm_db.so (pstack utility support)


Thanks,
Serguei
>
> Regards,
>
> Bertrand.
>