RFR(S): 8068945: Use RBP register as proper frame pointer in JIT compiled code on x86
zoltan.majo at oracle.com
Mon Mar 30 12:08:42 UTC 2015
On 03/27/2015 08:52 PM, Dean Long wrote:
> Hi Zoltan. These changes look good.
thank you for the feedback!
> 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.
I filed the enhancement JDK-8076227: "Cleanup unused method invocation
logic" for that purpose. I hope I can spend on time on it soon.
Thank you and best regards,
> 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
>> Thank you and best regards,
>>  http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d7922586cf6
More information about the hotspot-compiler-dev