Summary

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%.

Description

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: