copyright on your FDLIBM java port

Tue Jul 1 15:21:11 UTC 2014

adding graal-dev to the copy list...

Hi Gustav --

My name is Tom Deneau and myself and some colleagues here at AMD have been working adding an HSA backend to the OpenJDK graal project.  http://openjdk.java.net/projects/graal/   (HSA is an architecture for offloading computation to GPUs).

One of the things we wanted to enable was the java.lang.Math functions with the necessary accuracy.  We cannot use the native host implementations of these math functions from the GPU but Graal provided a way (called MethodSubstitution) to override the java.lang.Math native routines with java routines.

We saw your port of FDLIBM back posted back in Aug 2009 and thought that would be good to use for this purpose.

http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html.  It is nicely written code and is working well for us in our testing but when we wanted to contribute the code to the graal project, there seems to be an issue with the copyright header which you can read below.

The graal webrev we are contributing along with a very slightly modified version of your original contribution can be seen here.  http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/

Is it OK to change the copyright header to the current Oracle OpenJDK copyright header shown here...

-- Tom Deneau

  1 /*

   2  * Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved.

   3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

   4  *

   5  * This code is free software; you can redistribute it and/or modify it

   6  * under the terms of the GNU General Public License version 2 only, as

   7  * published by the Free Software Foundation.

   8  *

   9  * This code is distributed in the hope that it will be useful, but WITHOUT

  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

  12  * version 2 for more details (a copy is included in the LICENSE file that

  13  * accompanied this code).

  14  *

  15  * You should have received a copy of the GNU General Public License version

  16  * 2 along with this work; if not, write to the Free Software Foundation,

  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

  18  *

  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

  20  * or visit www.oracle.com<http://www.oracle.com> if you need additional information or have any

  21  * questions.

  22  */

  23

-----Original Message-----

From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com]

Sent: Tuesday, July 01, 2014 9:11 AM

To: Deneau, Tom

Cc: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>; Doug Simon

Subject: Re: webrev-hsail-transcendentals

Tom,

We cannot ourselves change the copyright header. Either Gustav contributes the code under the current OCA or he shares copyright with AMD such that you can yourself contribute.

Thanks, thomas

On 01 Jul 2014, at 08:34, Doug Simon <doug.simon at oracle.com<mailto:doug.simon at oracle.com>> wrote:

> I will integrate this patch. However, to do so, I need to change the header for JStrictMath so that it passes 'mx checkheaders'. The header is currently:

>

> /*

> * Copyright 1999-2006 Sun Microsystems, Inc.  All rights reserved.

> * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

> */

>

> Can we simply change this to the expected Oracle copyright header?

>

> -Doug

>

> On Jun 30, 2014, at 9:56 PM, Deneau, Tom <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:

>

>> Please review the following webrev which adds support for several missing java.lang.Math routines to the HSAIL backend.

>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-transcendentals/webrev/

>>

>> Many of these routines were declared as native in the regular host backends, but HSAIL has no way to invoke host code from the kernels.  But if we could find java implementations of these methods we could use those thru the graal MethodSubstitution framework.  For the java implementations, we basically used a file StrictMath.java which Gustav Trede donated to OpenJDK back in 2009 as a java port of the C FDLIBM routines, thank you Gustav.

>>    http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001992.html

>>

>> We made only a few minor changes to that file.     My understanding from  Joe Darcy is that in Java 9 there will be an official port of FDLIBM to java in the JDK, so when that happens we should be able to use that instead.

>>

>>

>> Notes:

>>

>> *         JStrictMath.java is the java implementation of the Math routines noted above.  HSAILMathSubstitutions redirects several methods to there.  In addition test cases were added for many Math routines which were already implemented as java methods in java.lang.Math.

>>

>> *         GraalTest --

>>

>> o   Since the java spec specifies the tolerance for most of these Math routines in terms of ULPs, I wanted to enable a way for AssertEquals to use ULPs rather than a constant maximum delta.   This is done by overriding protected int ulpsDelta() to return something other than zero.

>>

>> *         HSAILAssembler

>>

>> o   fix the printing of some special Double and Float constants

>>

>> o   cvt for float to integer uses zeroi_sat (saturate)

>>

>> *         HSAILLIRGenerator & HSAILControlFlow

>>

>> o   IntegerTestMove support was required by some of the java implementations

>>

>> *         all the rest are just junit tests.

>>

>> All junit tests should pass on the simulator.  These math routines have also been useful in solidifying the hsail hardware implementation.

>>

>> -- Tom

>>

>