[9] RFR(S): 8068945: Use RBP register as proper frame pointer in JIT compiled code on x86

[Dean Long]

Hi Zoltan.  These changes look good.  However I would like to see a 
followup bug to
investigate if all the MH save/restore SP logic can be removed for other 
platforms
as well.

dl

On 3/27/2015 7:34 AM, Zoltán Majó wrote:
> Hi,
>
>
> please review the following patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068945
>
>
> Problem:
>
> The RBP register is currently not as a proper frame pointer. As a 
> result, external tools (e.g., Linux's perf) are not able to walk the 
> VM's stack.
>
> The interpreter already uses the RBP register as a proper frame 
> pointer. A patch by Brendan Gregg (listed in JBS) partially enables 
> using RBP for C1 and C2. For C1, RBP is not available to the register 
> allocator by default, so adjusting the method call prologue works for 
> most cases. For C2, removing RBP from the list of available registers 
> and adjusting the method call prologue also works for most cases.
>
> Brendan's patch, however, does not consider method handle invocations.
>
> The VM considers a method handle invocation to potentially corrupt the 
> stack pointer (SP) of its caller (the method that contains the 
> invocation). To avoid corrupting the stack, the caller's SP is saved 
> into RBP before a method handle invoke and is restored afterwards (RBP 
> is a callee-saved register).
>
>
> Solution:
>
> My observation is (and please correct me if I'm wrong) that on x86 
> method handle invocations do not change the SP of their caller. Here 
> are some details about that.
>
> Currently, a method handle invocation is either (1) a method handle 
> intrinsic or (2) a compiled lambda form.
>
> (1) We currently have five method handle intrinsics:
>
> _invokeBasic
> _linkToVirtual
> _linkToStatic
> _linkToSpecial
> _linkToInterface
>
> On x86, none of these intrinsics change the SP; these intrinsics 
> directly jump to an appropriate target without modifying the SP. (I 
> think, SP changes were possible before JDK-7023639 was pushed, for 
> example in MethodHandles::remove_arg_slots() [1].)
>
> (2) Compiled lambda forms do not change the SP of their caller because 
> a compiled lambda form is a method that can be interpreted/compiled 
> the usual way.
>
> In summary, method handle invocations do not change the caller's SP on 
> x86, hence saving/restoring the SP of the caller of a method handle 
> invocation is not necessary on x86. This patch proposes to avoid 
> saving/restoring the SP on method handle invocations on x86 (but to 
> still save/restore the SP on other architectures).
>
> Having a proper frame pointer potentially results in performance 
> degradation because there is one less register available to the 
> register allocator. This patch introduces a new flag, 
> OmitFramePointer. RBP is used as a frame pointer on x86_32 and x86_64 
> only if OmitFramePointer is false.
>
>
> Webrev: http://cr.openjdk.java.net/~zmajo/8068945/webrev.00/
>
>
> Full JPRT run, all tests pass. I also ran all hotspot compiler tests 
> and the jdk tests in java/lang/invoke on both x86_64 and x86_32. All 
> tests that pass without the patch pass also with the patch.
>
> I ran the SPEC JVM 2008 benchmarks on our performance infrastructure 
> for x86_64. The performance evaluation suggests that there is no 
> statistically significant performance degradation due to having proper 
> frame pointers. Therefore I propose to have OmitFramePointer set to 
> false by default on x86_64 (and set to true on all other platforms).
>
>
> Thank you and best regards,
>
>
> Zoltan
>
>
> [1] http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d7922586cf6