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

[Zoltán Majó]

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