My team is in the process of proposing and implementing some System property
changes for JDK8 to help
identify specific processor characteristics and operating system platforms that
might be needed in the future.
The immediate need is for the detection of arm hard-float ABI but the other
properties are being added in
case we need them while the window is open.
OS.ARCH ADDITIONS
-----------------------------
Embedded processors support a variety of CPU configurations that are not all
binary compatible. If a developer needs to provide native binaries for one or
more of these configurations, they need a way of querying the platform
constraints in order to load the appropriate JNI shared library.
Here's a specific example of this issue:
There are three predominate binaries that we support Java for Linux ARM
platforms on.
1. Full soft-floatABI (No floating point instructions)
2. VFP with softfp ABI (floating arguments are not passed in floating point
registers)
3. VFP with hard float ABI (floating pointer arguments passes in registers)
The first two (1,2) options are binary compatible at the ABI level. The only
difference is the use of VFP instructions and if you are running on a processor
that can execute them.
The third option is a new ABI and is incompatible with the older ABIs unless
you are running on a system that supports multi-arch.
Developers are requesting a way to identify which ABI Java is currently using
in order to select a compatible native library when using JNI.
Solution
I propose adding a few new System properties that can be used to provide
additional
information beyond the basic os.arch values for ARM as well as other processor
architectures. These properties will all be optional. Although these properties
are
under the os name space, this was done to be consistent with the os.arch and
other
pre-existing properties. The new properties being define here define the mode
in which the processor is being used by the running Java process rather than
defining the capabilities of the OS. These are obviously related but the OS for
example might be capable of running both 32 and 64 bit programs but the value
returned for os.arch.datamodel will return 32 if the running process is a 32
bit Java process.
os.arch.endian
---------------------
This property if available will return either "big" or "little" depending on
which endian mode the processor is executing in.
os.arch.variant
---------------------
This property, if available, is a free form description of the specific
processor architecture. See examples below.
os.arch.fpu
----------------
This property, if available, describes the specific floating point execution
unit that is being used by the Java process. If floating point instructions are
emulated, this property will return "none".
os.arch.abi
----------------
This property, if available, describes if the floating point calling convention
is hardfloat or softfloat.
os.arch.datamodel
---------------------------
This property, if available, reports that the running process is executing in
either 32 bit or 64 bit mode.
The "release" file located in the top level JRE directory should also be
enhanced to include these new properties as OS_ARCH_ENDIAN, OS_ARCH_VARIANT,
OS_ARCH_FPU, OS_ARCH_ABI and OS_ARCH_DATAMODEL.
EXAMPLES
------------------
Here are some options for ARM processors (os.arch == arm)
os.arch.endian { big, little}
os.arch.variant {cortex-a8, cortex-a9, armv5, armv6, armv7}
os.arch.fpu {vfp, neon, none}
os.arch.abi {softfloat, hardfloat}
os.arch.datamodel {32, 64}
Here are some options for PowerPC (os.arch == ppc)
os.arch.endian { big, little}
os.arch.variant {e500v2, e500mc, e600}
os.arch.fpu {booke, altivec, spe, none }
os.arch.abi {softfloat, hardfloat}
os.arch.datamodel {32, 64}
* although existing properties exist for datamodel and endian in the sun.*
namespace, they are duplicated here
for consistency and to make it easier for developers to find.
OS.VARIANT ADDITIONS
------------------------------
The current os.name System property does not provide sufficient information for
identifying the specific platform that the Java runtime is running on. New
platforms that are derived from existing platforms but have unique requirements
may require special support. If someone were to port JDK8 to the Apple iOS
platform, they could use much of the Mac OS X implemenation. This platform
shares most of the same underlying operating system interfaces based on Darwin
but some of the APIs are subsetted. A similar issue would arise in an attempt
to support Java applications on Android operating systems which is a unique
implementation of Linux.
Interface summary
exported external property os.variant, os.variant.version
Solution
I propose we add a new System property (os.variant) that will provide the
specific OS implementation.
Since Android is really a specific variant of Linux, os.name will report Linux
while os.variant will report Android.
In addition, we will add an os.variant.version that will report the specific
version. In the Android example, os.version will report the underlying Linux
version, but os.variant.version will report the Android specific version (2.6,
4.1 for example).
For Apple, I propose to maintain the current Mac OS X value for os.name but use
iPhone OS for the os.variant and the specific iPhone OS version for
os.variant.version.
These os.variant property will also be added to the "release" file located in
the top level JRE directory as OS_VARIANT.
Specification
A new os.variant String property will be optionally available in a running Java
process to identify which Operating System Platform the Java process is running
on.
A new os.variant.version String property will be available in a running Java
process to identify the specific version of the Operating System Platform that
the Java processes is currently executing on. This property is also optional.
Examples of Operating System Platforms would be:
Android
iPhone OS
Ubuntu
Debian
Raspbian
