RFR(S): 8068945: Use RBP register as proper frame pointer in JIT compiled code on x86
dean.long at oracle.com
Fri Mar 27 19:52:13 UTC 2015
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
On 3/27/2015 7:34 AM, Zoltán Majó wrote:
> please review the following patch.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068945
> 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).
> 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:
> 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() .)
> (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,
>  http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d7922586cf6
More information about the hotspot-compiler-dev