New CPU & OS Platform System Properties
aph at redhat.com
Wed Jan 9 02:59:55 PST 2013
On 01/08/2013 08: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.
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.
> 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
> 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.
> 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, 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
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
May I suggest a simple list of flags that indicate per-platform
More information about the porters-dev