Summary

Reduce the dynamic memory used by core-library classes without adverselyimpacting performance.

Success Metrics

Existing workloads and metrics including SPECjbb2005 and SPECjvm98 willbe used to judge the benefit and impact of these changes.

Motivation

Reducing the dynamic memory (heap) usage of core-library classes willincrease the size of applications that can be run within a givenallocation of memory for the Java runtime, allow more applications to berun with the same dynamic footprint, and increase the throughput ofapplications due to more efficient memory usage.

Description

The work to find practical reductions in the amount of dynamic memoryparallels other performance work. Typical workloads will be identifiedand examined to identify likely opportunities for improvements. Variousimprovements to library classes to reduce heap usage and improve relatednative implementations will be prototyped and evaluated foreffectiveness. The performance impact will be measured using existingworkloads and metrics including SPECjbb2005 and SPECjvm98.

The improvements that reduce dynamic memory usage while not impactingperformance and are long-term maintainable in the source will beincorporated. Changes that are only effective for some applicationsshould be configurable so they can be enabled or disabled as needed.

Candidate: Reduce Object Sizes

Several fields injava.lang.Class are used only when particularoperations are applied to a class, such as reflection, annotationaccesses, and class redefinition (via JVMTI).

Moving these fields to a separate helper class could reduce the size ofClass objects when those fields are not needed. Conversely, however, itmust be noted that if any of the fields are needed then we not only needto restore the same effective object size, we have added 4 bytes for thehelper reference and 8 bytes for the helper object itself.

The fields supporting reflection caching and annotations can be moved toa helper class without impact to the VM or serialization. The reflectionand annotation information accessors are not particularlyperformance-sensitive, but the performance impact due to the indirectionshould be measured and potentially mediated.

In general, moving infrequently-used fields to helper classes will reduceallocations in the typical case but the additional indirection may have aperformance impact that must be measured and taken into consideration.

Candidate: Disable the Reflection Compiler

The reflection compiler generates bytecodes for method calls to improveperformance. Disabling the compiler would reduce dynamic footprint. Theperformance penalty can be substantial on specially-crafted tests but isexpected to be fairly small on typical applications, which do not relyheavily on reflection.

Candidate: Miscellaneous Memory Reductions

Other memory reductions need to be investigated by analyzing heap usagewithin candidate applications. Possible reductions include tuning theinitial sizes of internal tables, caches, and buffers to reduce wastage.