JEP 149: Reduce Core-Library Memory Usage
| Authors | Roger Riggs, Hinkmond Wong, David Holmes |
| Owner | Roger Riggs |
| Type | Feature |
| Scope | Implementation |
| Status | Closed / Delivered |
| Release | 8 |
| Component | core-libs |
| Discussion | core dash libs dash dev at openjdk dot java dot net |
| Effort | M |
| Duration | M |
| Reviewed by | Brian Goetz |
| Endorsed by | Brian Goetz |
| Created | 2012/01/04 20:00 |
| Updated | 2016/02/18 21:20 |
| Issue | 8046139 |
Summary
Reduce the dynamic memory used by core-library classes without adversely impacting performance.
Success Metrics
Existing workloads and metrics including SPECjbb2005 and SPECjvm98 will be used to judge the benefit and impact of these changes.
Motivation
Reducing the dynamic memory (heap) usage of core-library classes will increase the size of applications that can be run within a given allocation of memory for the Java runtime, allow more applications to be run with the same dynamic footprint, and increase the throughput of applications due to more efficient memory usage.
Description
The work to find practical reductions in the amount of dynamic memory parallels other performance work. Typical workloads will be identified and examined to identify likely opportunities for improvements. Various improvements to library classes to reduce heap usage and improve related native implementations will be prototyped and evaluated for effectiveness. The performance impact will be measured using existing workloads and metrics including SPECjbb2005 and SPECjvm98.
The improvements that reduce dynamic memory usage while not impacting performance and are long-term maintainable in the source will be incorporated. Changes that are only effective for some applications should be configurable so they can be enabled or disabled as needed.
Candidate: Reduce Object Sizes
Several fields in java.lang.Class are used only when particular
operations are applied to a class, such as reflection, annotation
accesses, and class redefinition (via JVMTI).
Moving these fields to a separate helper class could reduce the size of
Class objects when those fields are not needed. Conversely, however, it
must be noted that if any of the fields are needed then we not only need
to restore the same effective object size, we have added 4 bytes for the
helper reference and 8 bytes for the helper object itself.
The fields supporting reflection caching and annotations can be moved to a helper class without impact to the VM or serialization. The reflection and annotation information accessors are not particularly performance-sensitive, but the performance impact due to the indirection should be measured and potentially mediated.
In general, moving infrequently-used fields to helper classes will reduce allocations in the typical case but the additional indirection may have a performance impact that must be measured and taken into consideration.
Candidate: Disable the Reflection Compiler
The reflection compiler generates bytecodes for method calls to improve performance. Disabling the compiler would reduce dynamic footprint. The performance penalty can be substantial on specially-crafted tests but is expected to be fairly small on typical applications, which do not rely heavily on reflection.
Candidate: Miscellaneous Memory Reductions
Other memory reductions need to be investigated by analyzing heap usage within candidate applications. Possible reductions include tuning the initial sizes of internal tables, caches, and buffers to reduce wastage.
