JEP 148: Small VM
|Component||hotspot / runtime|
|Discussion||hostspot dash dev at openjdk dot java dot net|
|Reviewed by||Bob Vandette|
|Endorsed by||Mikael Vidstedt|
Support the creation of a small VM that is no larger than 3MB.
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.
There is no plan to retain full capabilities. There is no plan to make functionality optional at runtime.
The size of
libjvm.so is less than 3MB, and performance is degraded by
no more than 5%.
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.
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
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
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,
sun.management, and monitoring (part
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
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
-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.
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
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.