New CPU & OS Platform System Properties Updated

[Bob Vandette]

Thanks for all the input.  Here's an update to the proposal based on the feedback I've received so far.

OS.ARCH ADDITIONS
-----------------------------

Since the proposed additions do not completely solve the problem of identifying all characteristics of
CPUs, I am going to back of on trying to standardize the old sun.* properties into os.arch versions.
A future API should be proposed to solve this problem if the immediate fix doesn't solve enough
of the existing problems.

I propose that we rely on the existing sun.* properties for the sun.cpu.endian, sun.arch.datamodel,
and sun.cpu.isalist.  

We will populate the sun.cpu.isalist with the contents of /proc/cpuinfo Features or flags entry on 
Linux platforms, if available, to give developers more visibility into available CPU features.

The only remaining problem is that of ABI.  For this I propose the addition of a single new property.

os.arch.abi 

This will be set to the industry standard abi name that toolchain vendors use.

For Linux and Android these would be:

gnueabi
gnueabihf    (signifying the EABI hard float ABI)
androideabi


OS.NAME ADDITIONS
-----------------------------

My proposal below for os.name stands with the exception of Apple platforms.  For iPhone and iPad
Java implementations, we will be setting os.name to "iOS" since Apple informed me that there
is really no concrete specified relationship between OSX and iOS.  They are two very distinct OS platforms
and should be treated as such.

I would still like to propose os.variant and os.variant.version for Android.

Let me know if anyone has objections to this updated proposal.

Bob Vandette
Java SE Embedded Lead



On Jan 8, 2013, at 3:29 PM, Bob Vandette wrote:

> 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130110/842962d4/attachment-0001.html