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

Change ConstantPool entry size from 64 bits to 32 bits


    • Type: Enhancement
    • Status: Open
    • Priority: P2
    • Resolution: Unresolved
    • Affects Version/s: 9
    • Fix Version/s: 10
    • Component/s: hotspot
    • Labels:


      Currently on 64-bit VM, each entry in ConstantPool is 64-bits. However, most entries need only 32-bits of information (due to the way Java class files are formatted). The only exceptions are Klass and Symbol pointers, which need to be pointer-sized.

      After JDK-8171392, Klass pointers are removed from the ConstantPool. So we only need a way to encode the Symbol pointers in 32-bit:

      Shared Symbols:

      For a shared Symbol, it's always within 32-bits of SharedBaseAddress. After JDK-8072061, we can enforce it to be within 1GB of SharedBaseAddress. So a shared Symbol* SS can be encoded as (SharedBaseAddress - SS), which is a 32-bit negative number.

      Dynamically Allocated Symbols:

      Each dynamically allocated Symbol DS stored in a ConstantPool is always stored in the runtime SymbolTable. This means there's a HashtableEntry<Symbol*> E, where

           E->literal() == DS

      We can use a special allocator for the HashtableEntries for the runtime SymbolTable, such that all of these HashtableEntries are within 1GB from a base address B. Thus, DS can be encoded as (DS - B), which is a 32-bit positive number.

        Symbol* symbol_at(int which) const {
          assert(tag_at(which).is_utf8(), "Corrupted constant pool");
          return *symbol_at_addr(which);

        Symbol* symbol_at(int which) const {
          assert(tag_at(which).is_utf8(), "Corrupted constant pool");
          int value = *int_at_addr(which);
          if (value < 0) {
              return (Symbol*)(SharedBaseAddress - value);
         } else {
             HashtableEntry<Symbol*, mtSymbol>* e = (HashtableEntry<Symbol*, mtSymbol>*)(_symbol_table_entries_base + value);
             return e->literal();

        Issue Links


          There are no comments yet on this issue.


            • Assignee:
              iklam Ioi Lam
              iklam Ioi Lam
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: