Discussion:
New CPU & OS Platform System Properties
(too old to reply)
Bob Vandette
2013-01-08 20:29:23 UTC
Permalink
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
Andrew Haley
2013-01-09 10:59:55 UTC
Permalink
Post by Bob Vandette
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.
Good idea. We seem to have made a bit of a mess of this in Linux on
the ARM architecture, so it's good to be thinking about it now.
Post by Bob Vandette
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.
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.
Right, I've seen that problem too.
Post by Bob Vandette
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.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".
I'm not at all sure about this one: it seems inadequate to describe
the variations possible. On the CPU I'm running the flags are:

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic
popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid

Not all of these refer to FPU capabilities, but FPU, SSE, SSE2, SSSE3
do.

Even on an ARMv7 the flags are

swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls

The FPU flags are VFP VFPV3 VFPV3D16.

On Linux, several of these are relevant to the choice of binary to run.

In many cases you can assume that if an arch supports VFPV3 it must
also support VFP. But there are other things that control the
selection of a binary, such as Thumb. Thumb 2 binaries don't run on
Raspberry Pi.

May I suggest a simple list of flags that indicate per-platform
capabilities?

Andrew.
Thomas Stüfe
2013-01-09 13:58:37 UTC
Permalink
Hi,

it would be nice to be able to distinguish between
a) "the architecture the VM is built for" (which is os.arch, I think) vs
b) "the architecture it is running on".

Usually its the same, but not always, as some OSes are able to start
different binary types.

- running an x86 (32bit) VM on x64.
- running an x86 VM on ia64 (which at least on Windows works)
- more exotic example, running an parisc VM on HP-UX itanium

You need (a) to make decisions about which native libraries to load at
some point. You also may need (b), though I am hard pressed to find an
example.

Thomas Stuefe
SAP Germany
Bob Vandette
2013-01-09 22:47:15 UTC
Permalink
Post by Thomas Stüfe
Hi,
it would be nice to be able to distinguish between
a) "the architecture the VM is built for" (which is os.arch, I think) vs
b) "the architecture it is running on".
Usually its the same, but not always, as some OSes are able to start
different binary types.
- running an x86 (32bit) VM on x64.
- running an x86 VM on ia64 (which at least on Windows works)
- more exotic example, running an parisc VM on HP-UX itanium
You need (a) to make decisions about which native libraries to load at
some point. You also may need (b), though I am hard pressed to find an
example.
You are correct that there are a couple of dimensions to this problem but I
am only trying to address (a) at the moment. I also haven't been able to come
up with a use case for (b) other than for crash dumping. In the crash dump case,
we do gather and report significantly more CPU and OS details.

Bob.
Post by Thomas Stüfe
Thomas Stuefe
SAP Germany
Bob Vandette
2013-01-09 22:39:54 UTC
Permalink
Post by Andrew Haley
Post by Bob Vandette
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.
Good idea. We seem to have made a bit of a mess of this in Linux on
the ARM architecture, so it's good to be thinking about it now.
Post by Bob Vandette
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.
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.
Right, I've seen that problem too.
Post by Bob Vandette
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.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".
I'm not at all sure about this one: it seems inadequate to describe
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic
popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
Not all of these refer to FPU capabilities, but FPU, SSE, SSE2, SSSE3
do.
Even on an ARMv7 the flags are
swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls
The FPU flags are VFP VFPV3 VFPV3D16.
On Linux, several of these are relevant to the choice of binary to run.
In many cases you can assume that if an arch supports VFPV3 it must
also support VFP. But there are other things that control the
selection of a binary, such as Thumb. Thumb 2 binaries don't run on
Raspberry Pi.
May I suggest a simple list of flags that indicate per-platform
capabilities?
I was really trying to propose the minimal number of property additions that
would solve the problems where major ABI incompatibility exists for shared libraries.
I'm not proposing a general purpose CPU capabilities API. This would be better
implemented in a new Java API rather than an extension of System Properties.
Given that we're 3 weeks away from JDK8 code freeze, a new API is out
of the question. I'd welcome a JEP proposal for JDK9 to add the full set of
options.

Also, the properties I'm proposing are not an attempt to detect and report all of
the underlying platform options as much as the mode that the VM was built and
is currently running in, and to define the major CPU/ABI requirements for JNI
shared libraries.

Bob.
Post by Andrew Haley
Andrew.
Andrew Haley
2013-01-09 13:40:18 UTC
Permalink
Post by Bob Vandette
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.
I wonder if it might be better to shift the burden of selecting a
working DSO to ld.so: try to dlopen() several DSOs, until you find one
that works.
This would need a precise ABI specification at the ELF level, and ld.so
would have to reject loading ABI-incompatible DSOs.
Yes, but we're already into the problem of ARM having insufficient flags
in the DSO to identify compatibility. It's being fixed now, I believe,
but there are a lot of systems out there.

Andrew.
Florian Weimer
2013-01-09 13:17:21 UTC
Permalink
Post by Bob Vandette
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.
I wonder if it might be better to shift the burden of selecting a
working DSO to ld.so: try to dlopen() several DSOs, until you find one
that works.

This would need a precise ABI specification at the ELF level, and ld.so
would have to reject loading ABI-incompatible DSOs.
--
Florian Weimer / Red Hat Product Security Team
John Coomes
2013-01-10 01:30:03 UTC
Permalink
Post by Bob Vandette
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
-----------------------------
...
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.
The property name os.arch.abi is too generic to be used only for
floating point info; os.arch.abi.float (or similar) would be better.
Unless you expect this property to contain a list of values describing
various abi properties in the future.
Post by Bob Vandette
os.arch.datamodel
---------------------------
This property, if available, reports that the running process is executing in either 32 bit or 64 bit mode.
os.arch.datamodel should be os.arch.data.model (similar to
sun.arch.data.model), since it's both familiar and easier to read.

The endian property also relates to the data format of the
architecture; it could be renamed os.arch.data.endian.

-John
Post by Bob Vandette
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.
Android
iPhone OS
Ubuntu
Debian
Raspbian
Dmitry Samersoff
2013-01-10 14:49:15 UTC
Permalink
Bob,

I think we are creating a property mess and still doesn't not cover all
cases.

So IMHO, it's better to create something like

os.arch.platform_string

and put there a string like

x86_64-pc-linux-gnu or armv7-linux-gnueabi-vfp

to solve immediate needs, then think about
good API to query capabilities for JDK9

-Dmitry
Post by Bob Vandette
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.
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.
Android
iPhone OS
Ubuntu
Debian
Raspbian
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Xerxes Rånby
2013-01-10 15:26:14 UTC
Permalink
Post by Dmitry Samersoff
Bob,
I think we are creating a property mess and still doesn't not cover all
cases.
So IMHO, it's better to create something like
os.arch.platform_string
and put there a string like
x86_64-pc-linux-gnu or armv7-linux-gnueabi-vfp
to solve immediate needs, then think about
good API to query capabilities for JDK9
-Dmitry
Post by Bob Vandette
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.
I share the view of Dmitry.

We had a chat in #OpenJDK about one year ago how to solve this issue without having to designing a new namespace:
http://icedtea.classpath.org/wiki/New_os.arch_namespace_Architecture
I like the idea to re-use the existing namespace provided by the c/c++ compilers target name:
By using the compilers target name helps developers who cross compile jni code to select the right compiler for each platform they want to support.

Cheers
Xerxes
Bob Vandette
2013-01-10 15:52:40 UTC
Permalink
I'm not opposed to a short term solution like this but it feels very gnu/Linux centric.
This is why I proposed splitting out each critical characteristic.

The triplets that I've seen don't encode the specific arm version

Here are some examples for toolchains we use:

arm-none-linux-gnueabi

or

arm-linux-gnueabihf (for hard float ARM).

The Linux string is redundant since it's already captured in os.name and there's should
be no need for gnu. eabi is an important abi distinction although we don't currently support
oabi anyway. How would Windows VC++, ARM compilers, Sun, HP, IBM compilers get
represented??

There are already existing properties (although there are in the sun.* namespace) that cover these issues:

endian (sun.cpu.endian)
datamodel (sun.arch.data.model)
variant (isalist) (sun.cpu.isalist)
fpu (sun.cpu.isalist)


I don't believe we populate the isalist today for our ARM JRE's but this could be easily changed.

There are no properties that deal with abi issues such as softfloat so if a quick fix is needed,
this is where we should focus.


Bob.
Post by Xerxes Rånby
Post by Dmitry Samersoff
Bob,
I think we are creating a property mess and still doesn't not cover all
cases.
So IMHO, it's better to create something like
os.arch.platform_string
and put there a string like
x86_64-pc-linux-gnu or armv7-linux-gnueabi-vfp
to solve immediate needs, then think about
good API to query capabilities for JDK9
-Dmitry
Post by Bob Vandette
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.
I share the view of Dmitry.
http://icedtea.classpath.org/wiki/New_os.arch_namespace_Architecture
By using the compilers target name helps developers who cross compile jni code to select the right compiler for each platform they want to support.
Cheers
Xerxes
Bob Vandette
2013-01-10 18:59:58 UTC
Permalink
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
Post by Bob Vandette
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.
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.
Android
iPhone OS
Ubuntu
Debian
Raspbian
m***@oracle.com
2013-01-23 16:38:25 UTC
Permalink
Post by 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
-----------------------------
...
The only remaining problem is that of ABI. For this I propose the
addition of a single new property.
os.arch.abi
This makes sense, but since you're not proposing to add this new property
to the Platform Specification [1] its name should start with "jdk." or
"sun.". Current convention would be to use "jdk.", but given that the
names of existing closely-related properties already start with "sun."
(sun.arch.data.model, etc.), this new property should be named
"sun.arch.abi".
Post by Bob Vandette
This will be set to the industry standard abi name that toolchain
vendors use.
gnueabi
gnueabihf (signifying the EABI hard float ABI)
androideabi
Will this property be defined for regular Linux, Mac OS, or Windows
builds?
Post by Bob Vandette
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.
I don't think it makes sense to describe Android as a variant of Linux.
Sure, it's built on top of a Linux kernel, but the rest of the
environment is vastly different from the typical Linux distro where
"os.name" currently has the value "Linux".

In short form, Linux : Android :: Mac OS : iOS.

The "os.name" property should have the value "Android" on Android
devices, and "os.version" should be the Android version number.

Given that, I don't see a compelling need to introduce "os.variant"
properties at this time.

- Mark


[1] http://download.java.net/jdk8/docs/api/java/lang/System.html#getProperties%28%29
Bob Vandette
2013-01-23 18:00:07 UTC
Permalink
Post by m***@oracle.com
Post by 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
-----------------------------
...
The only remaining problem is that of ABI. For this I propose the
addition of a single new property.
os.arch.abi
This makes sense, but since you're not proposing to add this new property
to the Platform Specification [1] its name should start with "jdk." or
"sun.". Current convention would be to use "jdk.", but given that the
names of existing closely-related properties already start with "sun."
(sun.arch.data.model, etc.), this new property should be named
"sun.arch.abi".
Ok, I can live with sun.arch.abi. It's a shame we can't easily move these
to oracle.arch.* but that's for another CCC.
Post by m***@oracle.com
Post by Bob Vandette
This will be set to the industry standard abi name that toolchain
vendors use.
gnueabi
gnueabihf (signifying the EABI hard float ABI)
androideabi
Will this property be defined for regular Linux, Mac OS, or Windows
builds?
I was not planning on adding this property for any platform where the abi does not
vary within the same cpu family or where ABI changes are already covered by previously
available properties. For example, there's no need to distinguish 32 and 64 bit x86 ABIs
since we have an endian property that provides that distinction.
Post by m***@oracle.com
Post by Bob Vandette
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.
I don't think it makes sense to describe Android as a variant of Linux.
Sure, it's built on top of a Linux kernel, but the rest of the
environment is vastly different from the typical Linux distro where
"os.name" currently has the value "Linux".
In short form, Linux : Android :: Mac OS : iOS.
The "os.name" property should have the value "Android" on Android
devices, and "os.version" should be the Android version number.
Given that, I don't see a compelling need to introduce "os.variant"
properties at this time.
Here's the justifications that I have to support this addition:

1. It would avoid adding a lot of " || os.name == "Android" in several places in the JDK
and application sources where the code currently check for "Linux" resulting in faster
execution and less maintenance.

2. OpenJDK community feedback. Mike Swingler from Apple agrees with my position that Android is a variant.

3. Google sets the os.name == Linux for Android platforms, not "Android".

4. os.name is the operating system and not the specific platform. Android is built on
top of a compatible implementation of Linux. We don't set os.name to ubuntu or debian
for those platforms so I don't think we should equate Android to os.name.


Bob.
Post by m***@oracle.com
- Mark
[1] http://download.java.net/jdk8/docs/api/java/lang/System.html#getProperties%28%29
m***@oracle.com
2013-02-12 16:16:41 UTC
Permalink
(cleaning up old threads ...)
Post by Bob Vandette
Post by m***@oracle.com
Post by 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
-----------------------------
...
The only remaining problem is that of ABI. For this I propose the
addition of a single new property.
os.arch.abi
This makes sense, but since you're not proposing to add this new property
to the Platform Specification [1] its name should start with "jdk." or
"sun.". Current convention would be to use "jdk.", but given that the
names of existing closely-related properties already start with "sun."
(sun.arch.data.model, etc.), this new property should be named
"sun.arch.abi".
Ok, I can live with sun.arch.abi. It's a shame we can't easily move these
to oracle.arch.* but that's for another CCC.
Even if we could, we'd never rename these to oracle.arch.*. They are in
no way Oracle-specific.
Post by Bob Vandette
Post by m***@oracle.com
Will this property be defined for regular Linux, Mac OS, or Windows
builds?
I was not planning on adding this property for any platform where the
abi does not vary within the same cpu family or where ABI changes are
already covered by previously available properties. For example,
there's no need to distinguish 32 and 64 bit x86 ABIs since we have an
endian property that provides that distinction.
Okay.
Post by Bob Vandette
Post by m***@oracle.com
Post by Bob Vandette
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.
I don't think it makes sense to describe Android as a variant of Linux.
Sure, it's built on top of a Linux kernel, but the rest of the
environment is vastly different from the typical Linux distro where
"os.name" currently has the value "Linux".
In short form, Linux : Android :: Mac OS : iOS.
The "os.name" property should have the value "Android" on Android
devices, and "os.version" should be the Android version number.
Given that, I don't see a compelling need to introduce "os.variant"
properties at this time.
1. It would avoid adding a lot of " || os.name == "Android" in several
places in the JDK and application sources where the code currently
check for "Linux" resulting in faster execution and less maintenance.
Saving a few lines of code and a few conditional tests in the JDK source
code really doesn't buy much.

As to application code, I think calling Android a "Linux" will actually
require existing code to change if and when it's run on the JDK in an
Android environment. Code that tests the value of os.name in order to
construct a string that's then passed to Runtime.exec on a real Linux
system will not work on Android -- it will have to be augmented also to
test os.variant, and to do something else.
Post by Bob Vandette
2. OpenJDK community feedback. Mike Swingler from Apple agrees with my
position that Android is a variant.
I respectfully disagree. Android is based on a Linux kernel but the
userland is entirely different. The name of the property is "os.name",
not "kernel.name".
Post by Bob Vandette
3. Google sets the os.name == Linux for Android platforms, not "Android".
That's their mistake.
Post by Bob Vandette
4. os.name is the operating system and not the specific platform.
Android is built on top of a compatible implementation of Linux. We
don't set os.name to ubuntu or debian for those platforms so I don't
think we should equate Android to os.name.
You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with
Android. That's incorrect. The only thing all these systems have in
common is the Linux kernel. The userlands of Ubuntu, Debian, RHEL, and
Fedora are (roughly) compatible with each other. The userland of Android
is not.

I still don't see a compelling need to introduce an "os.variant"
property.

- Mark
Dmitry Samersoff
2013-02-12 16:35:44 UTC
Permalink
Mark,

Unfortunately, the problem is harder than it should be.

If you write gui-less program in plain C it's just linux-arm program
with minimal difference.

But gui and high level api is of course absolutely different. So final
decision depends mostly to the way Java customers will use this flag.

-Dmitry
Post by m***@oracle.com
(cleaning up old threads ...)
Post by Bob Vandette
Post by m***@oracle.com
Post by 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
-----------------------------
...
The only remaining problem is that of ABI. For this I propose the
addition of a single new property.
os.arch.abi
This makes sense, but since you're not proposing to add this new property
to the Platform Specification [1] its name should start with "jdk." or
"sun.". Current convention would be to use "jdk.", but given that the
names of existing closely-related properties already start with "sun."
(sun.arch.data.model, etc.), this new property should be named
"sun.arch.abi".
Ok, I can live with sun.arch.abi. It's a shame we can't easily move these
to oracle.arch.* but that's for another CCC.
Even if we could, we'd never rename these to oracle.arch.*. They are in
no way Oracle-specific.
Post by Bob Vandette
Post by m***@oracle.com
Will this property be defined for regular Linux, Mac OS, or Windows
builds?
I was not planning on adding this property for any platform where the
abi does not vary within the same cpu family or where ABI changes are
already covered by previously available properties. For example,
there's no need to distinguish 32 and 64 bit x86 ABIs since we have an
endian property that provides that distinction.
Okay.
Post by Bob Vandette
Post by m***@oracle.com
Post by Bob Vandette
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.
I don't think it makes sense to describe Android as a variant of Linux.
Sure, it's built on top of a Linux kernel, but the rest of the
environment is vastly different from the typical Linux distro where
"os.name" currently has the value "Linux".
In short form, Linux : Android :: Mac OS : iOS.
The "os.name" property should have the value "Android" on Android
devices, and "os.version" should be the Android version number.
Given that, I don't see a compelling need to introduce "os.variant"
properties at this time.
1. It would avoid adding a lot of " || os.name == "Android" in several
places in the JDK and application sources where the code currently
check for "Linux" resulting in faster execution and less maintenance.
Saving a few lines of code and a few conditional tests in the JDK source
code really doesn't buy much.
As to application code, I think calling Android a "Linux" will actually
require existing code to change if and when it's run on the JDK in an
Android environment. Code that tests the value of os.name in order to
construct a string that's then passed to Runtime.exec on a real Linux
system will not work on Android -- it will have to be augmented also to
test os.variant, and to do something else.
Post by Bob Vandette
2. OpenJDK community feedback. Mike Swingler from Apple agrees with my
position that Android is a variant.
I respectfully disagree. Android is based on a Linux kernel but the
userland is entirely different. The name of the property is "os.name",
not "kernel.name".
Post by Bob Vandette
3. Google sets the os.name == Linux for Android platforms, not "Android".
That's their mistake.
Post by Bob Vandette
4. os.name is the operating system and not the specific platform.
Android is built on top of a compatible implementation of Linux. We
don't set os.name to ubuntu or debian for those platforms so I don't
think we should equate Android to os.name.
You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with
Android. That's incorrect. The only thing all these systems have in
common is the Linux kernel. The userlands of Ubuntu, Debian, RHEL, and
Fedora are (roughly) compatible with each other. The userland of Android
is not.
I still don't see a compelling need to introduce an "os.variant"
property.
- Mark
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Mike Swingler
2013-02-12 16:47:10 UTC
Permalink
Post by m***@oracle.com
Post by Bob Vandette
2. OpenJDK community feedback. Mike Swingler from Apple agrees with my
position that Android is a variant.
I respectfully disagree. Android is based on a Linux kernel but the
userland is entirely different. The name of the property is "os.name",
not "kernel.name".
To be clear, I only mentioned that the "os.variant" scheme only made more sense for Linux than claiming that iOS is variant of OS X. My point was also predicated on ensuring that "os.version" would be linked to the Linux kernel version. I only asserted strongly that the variant scheme made no sense for iOS vs. OS X, and only conceded that it might make sense for Android vs. Linux.

Regards,
Mike Swingler
Apple Inc.
Bob Vandette
2013-02-12 16:52:20 UTC
Permalink
I've withdrawn my request to add a new os.variant. We'll just set os.name to Android.

I will use sun.arch.abi to identify platform specific ABI differences.

Bob.
Post by m***@oracle.com
(cleaning up old threads ...)
Post by Bob Vandette
Post by m***@oracle.com
Post by 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
-----------------------------
...
The only remaining problem is that of ABI. For this I propose the
addition of a single new property.
os.arch.abi
This makes sense, but since you're not proposing to add this new property
to the Platform Specification [1] its name should start with "jdk." or
"sun.". Current convention would be to use "jdk.", but given that the
names of existing closely-related properties already start with "sun."
(sun.arch.data.model, etc.), this new property should be named
"sun.arch.abi".
Ok, I can live with sun.arch.abi. It's a shame we can't easily move these
to oracle.arch.* but that's for another CCC.
Even if we could, we'd never rename these to oracle.arch.*. They are in
no way Oracle-specific.
Post by Bob Vandette
Post by m***@oracle.com
Will this property be defined for regular Linux, Mac OS, or Windows
builds?
I was not planning on adding this property for any platform where the
abi does not vary within the same cpu family or where ABI changes are
already covered by previously available properties. For example,
there's no need to distinguish 32 and 64 bit x86 ABIs since we have an
endian property that provides that distinction.
Okay.
Post by Bob Vandette
Post by m***@oracle.com
Post by Bob Vandette
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.
I don't think it makes sense to describe Android as a variant of Linux.
Sure, it's built on top of a Linux kernel, but the rest of the
environment is vastly different from the typical Linux distro where
"os.name" currently has the value "Linux".
In short form, Linux : Android :: Mac OS : iOS.
The "os.name" property should have the value "Android" on Android
devices, and "os.version" should be the Android version number.
Given that, I don't see a compelling need to introduce "os.variant"
properties at this time.
1. It would avoid adding a lot of " || os.name == "Android" in several
places in the JDK and application sources where the code currently
check for "Linux" resulting in faster execution and less maintenance.
Saving a few lines of code and a few conditional tests in the JDK source
code really doesn't buy much.
As to application code, I think calling Android a "Linux" will actually
require existing code to change if and when it's run on the JDK in an
Android environment. Code that tests the value of os.name in order to
construct a string that's then passed to Runtime.exec on a real Linux
system will not work on Android -- it will have to be augmented also to
test os.variant, and to do something else.
Post by Bob Vandette
2. OpenJDK community feedback. Mike Swingler from Apple agrees with my
position that Android is a variant.
I respectfully disagree. Android is based on a Linux kernel but the
userland is entirely different. The name of the property is "os.name",
not "kernel.name".
Post by Bob Vandette
3. Google sets the os.name == Linux for Android platforms, not "Android".
That's their mistake.
Post by Bob Vandette
4. os.name is the operating system and not the specific platform.
Android is built on top of a compatible implementation of Linux. We
don't set os.name to ubuntu or debian for those platforms so I don't
think we should equate Android to os.name.
You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with
Android. That's incorrect. The only thing all these systems have in
common is the Linux kernel. The userlands of Ubuntu, Debian, RHEL, and
Fedora are (roughly) compatible with each other. The userland of Android
is not.
I still don't see a compelling need to introduce an "os.variant"
property.
- Mark
Loading...