New CPU & OS Platform System Properties

[Bob Vandette]

On Jan 9, 2013, at 5:59 AM, Andrew Haley wrote:

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

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.


> 
> Andrew.