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

[Zoltán Majó]

Hi Dean,


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,


Zoltan

>
> 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
>