New CPU & OS Platform System Properties

Bob Vandette bob.vandette at
Tue Jan 8 12:29:23 PST 2013

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.


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.

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.
This property if available will return either "big" or "little" depending on which endian mode the processor is executing in.
This property, if available, is a free form description of the specific processor architecture. See examples below.
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".
This property, if available, describes if the floating point calling convention is hardfloat or softfloat.
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.
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.


The current 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
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, 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 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.
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:
iPhone OS

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the porters-dev mailing list