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

Per-CPU optimization of Klass range reservation



    • Enhancement
    • Resolution: Fixed
    • P4
    • 22
    • 22
    • hotspot
    • b26


      In `Metaspace::reserve_address_space_for_compressed_classes`, we reserve space for the future Klass range - either class space alone or class space + CDS. We place the Klass range somewhere that allows us to use "good" narrow Klass decoding later when initializing the encoding scheme.

      Since narrow Klass decoding is inherently CPU-specific (see the various variants of MacroAssembler::decode_klass()), this is awkward. It leads to many ifdefs, awkward, vague code comments that are difficult to grok, and missed optimization opportunities. It would be much better to have this section per CPU so that every CPU can implement its own perfect and perfectly documented version. A bit of code duplication is a good price for code clarity.

      (This results from lengthy discussions with Andrew Haley and many exhausting attempts to get this shared coding into a form that fits all CPUs and satisfies all reviewers).

      If we do that, we can do more targeted optimizations per CPU. For example:

      - on RiscV, we could go for a 64-bit immediate that only needs a single instruction to load

      - on both RiscV and s390, reserving < 4GB should be done unconditionally, regardless if we run with CDS or not. This is because even if CDS is enabled and we cannot use zero-based encoding, such an immediate is still cheaper to load.

      - on Aarch64, attempting to reserve for zero-based encoding (base=0 shift>0) is not necessary; lsl costs as much as a single movk (and I was told it was historically more expensive), so we should go for movk mode right away if unscaled is not an option


        Issue Links



              stuefe Thomas Stuefe
              stuefe Thomas Stuefe
              0 Vote for this issue
              4 Start watching this issue