Summary

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.