Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8068945

Use RBP register as proper frame pointer in JIT compiled code on x86

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b64
    • CPU:
      x86_64
    • OS:
      generic

      Backports

        Description

        We used rbp register for local values in jit compiled code on x86 because 32-bit mode have only few registers.
        We do the same in 64-bit VM but it may help less with performance since it has more registers.
        Using RBP only as frame pointer will help debugging and profiling tools.

          Issue Links

            Activity

            Hide
            zmajo Zoltan Majo added a comment -
            Thanks, David, for pointing that out!
            Show
            zmajo Zoltan Majo added a comment - Thanks, David, for pointing that out!
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/382e9e4b3b71
            User: lana
            Date: 2015-05-13 21:19:48 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/382e9e4b3b71 User: lana Date: 2015-05-13 21:19:48 +0000
            Hide
            idergali Ilya Dergalin added a comment -
            Was performance testing done for these changes?
            Show
            idergali Ilya Dergalin added a comment - Was performance testing done for these changes?
            Hide
            zmajo Zoltan Majo added a comment -
            Hi Ilya,


            yes, Robert Strout tested performance, please see below:

            "Sorry for the delay on getting the performance results... We've had most of
            the results for awhile, but one of the SPARC machines has been down which
            held up some of the results. Machine is still down, and not sure when it's
            coming back online. Those impacted results show in the results table as "Failed"...

            http://aurora.se.oracle.com/performance/reporting/report/robert.strout.JDK-8068945.Compare

            But we can ignore those since we don't need the SPARC results for this anyway.
            I can assess the performance results as follows...

                Overall, most of the benchmarks in Aurora.se shown no definitive change.

                There's strong evidence that this benchmark regresses on all x64 platforms:
                        SPECjvm2008-Compress* -2% to -3.5%
                       
                There's evidence that this benchmark regresses on all x64 platforms:
                        SPECjvm2008-Derby* -2% to -5%

            Normally, I would follow up with a run of derby with more data points to get
            a stronger measurement for it. And also do the same for a few weak results just
            to make sure something is not hiding there. But given this change is under a
            flag, I don't think we need to take this further. If you were going to consider
            making this the default, then I'd want to run all the SPECjvm2008 benchmarks with
            more iterations to better understand any impact it might have on the default.

            --Resii"


            PreserveFramePointer is off by default, so this change has no impact on VM performance in the default configuration.

            Best regards,


            Zoltan
            Show
            zmajo Zoltan Majo added a comment - Hi Ilya, yes, Robert Strout tested performance, please see below: "Sorry for the delay on getting the performance results... We've had most of the results for awhile, but one of the SPARC machines has been down which held up some of the results. Machine is still down, and not sure when it's coming back online. Those impacted results show in the results table as "Failed"... http://aurora.se.oracle.com/performance/reporting/report/robert.strout.JDK-8068945.Compare But we can ignore those since we don't need the SPARC results for this anyway. I can assess the performance results as follows...     Overall, most of the benchmarks in Aurora.se shown no definitive change.     There's strong evidence that this benchmark regresses on all x64 platforms:             SPECjvm2008-Compress* -2% to -3.5%                 There's evidence that this benchmark regresses on all x64 platforms:             SPECjvm2008-Derby* -2% to -5% Normally, I would follow up with a run of derby with more data points to get a stronger measurement for it. And also do the same for a few weak results just to make sure something is not hiding there. But given this change is under a flag, I don't think we need to take this further. If you were going to consider making this the default, then I'd want to run all the SPECjvm2008 benchmarks with more iterations to better understand any impact it might have on the default. --Resii" PreserveFramePointer is off by default, so this change has no impact on VM performance in the default configuration. Best regards, Zoltan
            Hide
            dtherkel David Therkelsen added a comment -
            Request for post-FC 8u60 backport for 8068945, 8075798 and 8080281 presented and approved at 5/27 RT mtg.
            Show
            dtherkel David Therkelsen added a comment - Request for post-FC 8u60 backport for 8068945, 8075798 and 8080281 presented and approved at 5/27 RT mtg.

              People

              • Assignee:
                zmajo Zoltan Majo
                Reporter:
                kvn Vladimir Kozlov
              • Votes:
                0 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: