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

Multiple alignments for Java objects


    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 9
    • Fix Version/s: 10
    • Component/s: hotspot
    • Labels:


      (I haven't found the relevant RFEs/discussions in JBS, please advise the duplicates, if any)


      Both 32-bit and 64-bit VMs are aligning the objects by 8 bytes. This wastes precious space since many objects' data is not taking up the entire 8-byte chunk. This RFE is to record the (very hard to do, but beneficial) optimization where runtime can select different alignments for different objects.


      This RFE is *very* long-shot, as it probably requires the significant changes in VM infra, GC, and possibly JIT compilers.

      32-bit VM case seems easy. There seems to be only the single reason to align the objects by 8 bytes: the presence of either longs or doubles, where misaligned long/double read can break the atomicity, produce the misaligned access trap, fall back to kernel recovery code, etc. However, when object does not have either long or double fields, we can align it by 4 bytes. Both mark and class words in object are 4-byte long in 32-bit mode, and so the accesses will be aligned.

      64-bit VMs are more complicated. The same reasoning about the fields still apply: if we have long/doubles we need to have 8-byte alignment to match internal field alignment by 8 bytes. Full-width references (-XX:-UseCompressedOops) should bail out of 4-byte alignment as well. However, the compressed references bring us back to 4-byte references. We probably can't guarantee the 8-byte mark word access alignment, and current mark word layout seems to indicate we sometimes need to have full-width atomic reads/writes. The class word is also 8-byte long without the compressed references, hence exhibits the same problem. With the default mode, compressed references enabled, however, it is 4-byte long, fitting nicely with 4-byte alignment.


      It only seems practical to segregate the power-of-two alignments, starting from 4 bytes. In current out-of-box VMs this means segregating into two groups: 4 byte alignments, and 8 byte alignments. The object alignment and the size of addressable heap with compressed references are intimately tied together. If we segregate 4-byte and 8-byte aligned objects, that would mean the compressed references should take the 4-byte-aligned addresses as the unit, thus limiting the addressable heap to 16 Gb with zero-based compressed oops.


      The study on the large corpus of class files (to be published soon) suggests the enormous improvements: >30% of classes enjoy lower alignment, with average saving of 4 bytes per instance.




            • Assignee:
              shade Aleksey Shipilev
            • Votes:
              0 Vote for this issue
              7 Start watching this issue


              • Created: