A hotspot patch for stack profiling (frame pointer)

[Brendan Gregg]

G'Day Serguei,

On Thu, Jan 15, 2015 at 1:26 PM, serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> 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)
>
>
Were these broken by the reuse of RBP as well? (I suspect so; I never
tested my RBP fix with DTrace jstack()).

Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150213/377215b5/attachment.html>