JEP 148: Small VM

Summary

Support the creation of a small VM that is no larger than 3MB.

Goals

Make necessary modifications so that we can optionally build a small VM no larger than 3MB. (For reference, the client and server VMs are currently around 6 and 9MB, respectively.)

This will be accomplished by allowing some features to be excluded at build time, and by optimizing the C++ compiled code for space when possible. A performance degradation with the small VM of up to 5% is acceptable. There must be no performance degradation with non-small builds.

Non-Goals

There is no plan to retain full capabilities. There is no plan to make functionality optional at runtime.

Success Metrics

The size of libjvm.so is less than 3MB, and performance is degraded by no more than 5%.

Motivation

Small devices have very strict static and dynamic memory-footprint requirements. To make Java to work well on such devices we need to reduce the JRE's overall static and dynamic footprint.

Description

An earlier effort to reduce the size of libjvm.so was undertaken when implementing the Java Kernel. The kernel VM removed many larger components such as extra garbage collectors, the C2 JIT, and most of JVMTI.

The kernel VM has not been maintained and was never implemented on Linux. The first step of this project is to revive the equivalent of that VM for Linux.

In the kernel VM, makefiles and related build files were modified to exclude the files unnecessary for required functionality. We are taking a slightly different approach and plan to modify the source files with conditionals rather than modify the build files. The existing conditional symbol KERNEL will become MINIMAL_JVM, and source files which the kernel VM excluded will be surrounded with #ifndef MINIMAL_JVM. In addition, for finer control of what's included in the minimal VM symbols such as INCLUDE_\<something> will be defined to include functionality which would otherwise be excluded. For the minimal VM these symbols will not be defined.

Once the minimal VM is stable on the requisite platforms, other unnecessary functionality will be made optional. The main way we think we can do this is to remove JVMTI, java.lang.instrument support (implemented in sun.instrument), sun.management, and monitoring (part of PerfDataManager) from the minimal VM.

Most of JVMTI has already been removed from the kernel VM. The remaining JVMTI code will be build-time conditionalized with #ifdef's.

Public APIs for removed functionality may need to be modified to throw appropriate exceptions when they are not implemented.

The other part of this project consists of finding the files which can be optimized for space without sacrificing performance. This involves modifying the build process such that it is easy to specify which files are to be optimized for space. The gcc option -Os is what we will use for most files to optimize for space. There may be other options to reduce space on some platforms. If there is a significant loss of performance, profiling will be used to determine which files can be compiled with -O3 to speed things up. This may involve moving functions around to different files so that only the functions needed for performance are compiled this way.

Testing

API's must behave appropriately if the underlying implementation code is missing. The changes must pass the Java SE 8 TCK. Performance testing will need to be done to measure the impact of the reduction work.

Risks and Assumptions

There may be VM dependencies on removed functionality of which we are unaware.

It is possible, but unlikely, that there is not enough optional functionality which can be removed to reach our goal.

It is assumed that JDK 8 will not significantly increase the size of libjvm.so.

Impact

• Other JDK components: Some tools may rely on missing code.

• Compatibility: JVMTI will not be supported in the minimal binary.

• Performance/scalability: Some minor impact to performance may be measured when this configuration is built.

• Documentation: Need to document what's not supported in the binary, and what happens if the user or tools try to access missing functionality.

• TCK: Some TCK changes may be needed to support API changes that result from removing features.

• QA: Extra testing will be needed to ensure the small binary works correctly. Tests may need to be updated to account for optional functionality.

• User experience: Users may expect full functionality on all VM's, but some functionality will be omitted from the small VM.