copyright on your FDLIBM java port

Wed Jul 2 20:45:37 UTC 2014

I have placed a new webrev with the javadoc modifications up at

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

(also merged with the later default tip).

-- Tom

From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com]
Sent: Tuesday, July 01, 2014 7:19 PM
To: Deneau, Tom
Cc: Doug Simon; gustav; dl.Runtimes
Subject: Re: copyright on your FDLIBM java port

I think this is fine. But we should somehow document that the class derives from (or tries to reimplement in Java the native methods defined in) java.lang.StrictMath.

- thomas

On 02 Jul 2014, at 00:14, Deneau, Tom <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:

Thomas, Doug --

Would this be correct for the javadoc?

Previously there were two @author lines,
*  @author unascribed
*  @author Joseph D. Darcy

or should I leave Joseph's name there?

-- Tom

/**
* The class {@code JStrictMath} contains methods for performing basic numeric operations such as
* the elementary exponential, logarithm, square root, and trigonometric functions.
*
* <p>
* To help ensure portability of Java programs, the definitions of some of the numeric functions in
* this package require that they produce the same results as certain published algorithms. These
* algorithms are available from the well-known network library {@code netlib} as the package
* "Freely Distributable Math Library," <a href="ftp://ftp.netlib.org/fdlibm.tar">{@code fdlibm}
* </a>. These algorithms, which are written in the C programming language, are then to be
* understood as executed with all floating-point operations following the rules of Java
* floating-point arithmetic.
*
* <p>
* The Java math library is defined with respect to {@code fdlibm} version 5.3. Where {@code fdlibm}
* provides more than one definition for a function (such as {@code acos}), use the
* "IEEE 754 core function" version (residing in a file whose name begins with the letter {@code e}
* ). The methods which require {@code fdlibm} semantics are {@code sin}, {@code cos}, {@code tan},
* {@code asin}, {@code acos}, {@code atan}, {@code exp}, {@code log}, {@code log10}, {@code cbrt},
* {@code atan2}, {@code pow}, {@code sinh}, {@code cosh}, {@code tanh}, {@code hypot},
* {@code expm1}, and {@code log1p}.
*
* @author Gustav Trede
* @since 1.3
*/

From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com]
Sent: Tuesday, July 01, 2014 4:43 PM
To: Deneau, Tom
Cc: Doug Simon
Subject: Re: copyright on your FDLIBM java port

Tom, you can go ahead preparing the webref with the standard header and a comment in the classes' javadoc that the code was contributed by gustav. - thomas

On 01 Jul 2014, at 23:37, gustav <gustav.trede at gmail.com<mailto:gustav.trede at gmail.com>> wrote:

thats ok for me. i have already signed the sun contributor agreement a long time ago. i tried to contribute my code to the openjdk. but there was a lack of QA resources ...

On 1 July 2014 23:28, Thomas Wuerthinger <thomas.wuerthinger at oracle.com<mailto:thomas.wuerthinger at oracle.com>> wrote:
Gustav,

Thank you very much for the possible contribution. We can acknowledge the authorship of the contribution both with a "Contributed-By:" commit message as well as with a mention of the author in the initial version of the contributed code. We can however not provide a special header and/or a commitment that such attribution will continue to exist in all future derivatives of the code. Such conditions are incompatible with the Oracle Contributor Agreement (OCA) [1], which is the only way we are allowed to receive contributions to our OpenJDK project. Please let us know whether this is OK for you and that you can contribute the code under the terms of the OCA.

Thanks, thomas

[1] http://www.oracle.com/technetwork/community/oca-486395.html

On 01 Jul 2014, at 22:51, Deneau, Tom <tom.deneau at amd.com<mailto:tom.deneau at amd.com>> wrote:

Thank you Gustav.

Doug S. or Thomas W. --

Can someone send Gustav for his review the proposed new header with the "contributed by" tag he is asking for.  Myself I am not sure what the official format is for such a tag.

-- Tom

From: gustav [mailto:gustav.trede at gmail.com]
Sent: Tuesday, July 01, 2014 3:27 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>; dl.Runtimes
Subject: Re: copyright on your FDLIBM java port

hello ,

Im happy my code found some usage :)
I gladly do whatever is most convenient and flexible for you regarding license as long as there is a written or contributed tag in the header with my name.

best regards
Gustav Trede
On 1 July 2014 17:21, Deneau, Tom <tom.deneau at amd.com<mailto:tom.deneau at amd.com><mailto:tom.deneau at amd.com>> wrote:

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/><http://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><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><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:

/*

* 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><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