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

JEP 147: Reduce Class Metadata Footprint


    • Type: JEP
    • Status: Closed
    • Priority: P4
    • Resolution: Delivered
    • Fix Version/s: 8
    • Component/s: hotspot
    • Labels:
    • Author:
      Jiangli Zhou
    • JEP Type:
    • Exposure:
    • Subcomponent:
    • Scope:
    • Discussion:
      hotspot dash runtime dash dev at openjdk dot java dot net
    • Effort:
    • Duration:
    • JEP Number:



      Reduce HotSpot's class metadata memory footprint in order to improve performance on small devices.

      Success Metrics

      Reduce class, method, and field metadata memory footprint by 25% as measured by calculating the space used by the relevant data structures (but excluding the space used for bytecodes and interned strings).

      The startup and runtime performance of typical applications must not regress by more than 1%.


      Many of the memory-reduction techniques used in CVM, an embedded JVM for Java ME CDC, can be applied to HotSpot. For example:

      • Keep rarely-used fields out of the class, method, and field data structures.

      • Make all struct fields as small as possible.

      • Encode some fields so that they fit into smaller types.

      • Don't mix field sizes in such a way that causes unnecessary padding (i.e., group types of similar sizes).

      • Use 16-bit offsets for some types of data rather than 32-bit pointers.

      • Use unions for groups of fields when no more than one is ever in use at the same time. Some fields will have different meanings based on the state the class is in.

      • Avoid storing the cb* in each fb and mb.

      • Methods are either abstract, native, or Java. Any data specific to one of these three types is kept in a separate struct, so the method data structure does not carry fields that are not always needed.

      • Data related to compiled methods is not allocated until the method is compiled.

      • Retaining Java debugging information is optional and usually disabled in production builds.

      • Constant pool entries (including type information) are 40 bits.

      • Compact the GC bitmap for describing which fields in a class are reference types. This usually fits in just 32 bits.

      • Limit the number of mallocs, and the resultant per-malloc block overhead, when allocating memory for a loaded class. Most of the class is laid out in one large malloc allocation.

      As an example, the following four boolean fields in instanceKlass.hpp can be combined into a single u1 field:

      bool _is_marked_dependent;   // used for marking during flushing & deopt
      bool _rewritten;             // methods rewritten
      bool _has_nonstatic_fields;  // for sizing with UseCompressedOops
      bool _should_verify_class;   // allow caching of preverification


      • Other JDK components: Tools that have knowledge of of class metadata formats


        There are no comments yet on this issue.


          • Assignee:
            jiangli Jiangli Zhou
            jiangli Jiangli Zhou
            Jiangli Zhou
            Reviewed By:
            Bob Vandette
            Endorsed By:
            Mikael Vidstedt
          • Votes:
            0 Vote for this issue
            1 Start watching this issue


            • Created: