New CPU & OS Platform System Properties

[Bob Vandette]

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.


On Jan 10, 2013, at 10:26 AM, Xerxes Rånby wrote:

> 2013-01-10 15:49, Dmitry Samersoff skrev:
>> 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
>> 
>> 
>> On 2013-01-09 00:29, 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.
> 
> 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

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