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

Devirtualize Relocation::type

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Fixed
    • P4
    • 15
    • 15
    • hotspot
    • b15

    Description

      Relocation classes defines type() as a virtual method. This virtual call has overhead that show up in places due compiler not being able to see through and optimize this even when the receiver is constant, see JDK-8240302

      An experiment[1] shows that it'd be possible to devirtualize this and replace the virtual call by storing the relocType in a field. This has some net beneficial effect on startup (and would probably have made JDK-8240302 redundant):

      Before:
             111,426,394 instructions # 0.81 insns per cycle ( +- 0.07% )
              22,024,611 branches # 422.957 M/sec ( +- 0.07% )
                 766,665 branch-misses # 3.48% of all branches ( +- 0.14% )

             0.037174222 seconds time elapsed ( +- 0.28% )

      After:
             110,927,871 instructions # 0.81 insns per cycle ( +- 0.07% )
              21,899,846 branches # 417.401 M/sec ( +- 0.07% )
                 760,536 branch-misses # 3.47% of all branches ( +- 0.15% )

             0.036918719 seconds time elapsed ( +- 0.26% )


      There's a small increase in the static libjvm.so size (~45kb, or 0.25%), due unlocking heavier inlining decisions somewhere higher up the call hierarchy.

      [1] http://cr.openjdk.java.net/~redestad/scratch/relocInfo.type.00/

      Attachments

        Activity

          People

            redestad Claes Redestad
            redestad Claes Redestad
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: