Java Grande Numerics Working Group Meeting
June 5, 2000
The working group reviewed the status of all ongoing projects and planned future work. Here we summarize the results of these discussions. For further information, see: Numerics Working Group homepage, and Java Grande Forum homepage.
SUMMARY OF DISCUSSION
Status of Java Releases
Java 1.3 has been shipped. A Java Specification Request (JSR) describing the changes proposed for Java 2 Standard Edition (J2SE) version 1.4 has already been submitted. Language and VM changes must be included in one of these umbrella JSRs in order to be deployed. (JSRs for particular language changes can be done asynchronously with this, but ultimately they must be folded into an umbrella JSR to actually be included in a particular release.) It is unlikely that any of the language and VM changes that we are currently working on will be ready in time for 1.4, which is targeted for release in 2001. Sun is working on a 12-18 month revision cycle.
Status of Java Community Process
A new version (2.0) of the Sun Community Process will be instituted shortly. Java Specification Requests (JSRs) which have previously been submitted will continue to be considered using the 1.0 process unless they request to be moved to 2.0. (Sun will be moving all the JSRs that it chairs to the 2.0 process.) The major difference in the process is an Executive Committee composed of representatives from about a dozen companies will have control of the process at critical decision points, (Previously, Sun had complete control.) These points are:
Individuals named to an expert group can now participate in work on that JSR at no cost, although signing an agreement with Sun is still required.
The gory details of the new process are outlined athttp://java.sun.com/aboutJava/communityprocess/review/jcp20/index.html. The process was outlined at a JavaOne panel. The slides from this talk are available at http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=1694&trackId=1&eventType=TS&ts=960856625273
Apparently, the Java Grande Forum cannot be listed as an endorsing party for JSRs since it is not a registered participant in the process.
IBM submitted this JSR several months ago. The JSR contains the following.
The actual impacts on the Java language would be minimal. Compilers would need to detect the new keyword and set a bit in the class file to indicate fpfast mode. The reflection API must be modified to sense this bit and return an appropriate indicator. Since optimizations are all optional, no additional changes need be made to assure conformance.
Sun responded fairly positively, but suggested that Sun lead the expert group. Tim Lindholm will do this.
The working group discussed whether the JSR should be more specific before submission. It was decided to continue the JSR in the current form.
Java Grande has already submitted its fastfp and array class JSRs under the 1.0 process. (This was actually done by IBM.) We should consider whether it is better to switch to the 2.0 process.
IBM submitted this JSR several months ago. The JSR proposes the multidimensional array API developed and implemented by IBM. Sun had several initial requests regarding the JSR.
The JSR contains the statement that the layout of the internal array is "logically" row-wise, but does not specify a physical layout. This allows compilers the greatest freedom to perform optimizations (by picking a layout that is best for a particular code). Others counter that this relies on compiler technology that may not be available for some time. Library developers need to know what to do today. For this they need to know the physical layout, and, in particular, need to obtain aliases to array sections so that they can operate on the internal data structure directly. The key point in the API where this disagreement shows up is in methods for extracting array sections: should this be a copy or should it be a pointer to the internal data structure. These issues may not be able to be resolved until later in the JSR process.
Roldan Pozo and Jose Moreira reported progress on the draft of a JSR for a Java language extension to introduce bracket notation for multidimensional arrays, e.g. a[i,j]. This new notation would be mapped to the standard multidimensional array class.
Some discussion ensued regarding whether Fortran-90-like array sections should be admitted. Most felt that this would complicate the JSR and jeopardize its chances. Instead, the JSR will focus exclusively on elemental access only.
It was not clear how to write the JSR without reference to the multidimensional array class JSR on whose approval this depends.
Considerable skepticism was aired regarding this JSR's chances. If multidimensional array syntax is to be based on the array class, then this class would have to be made part of the Java core. This class is quite large. This would conflict directly with current emphasis on keeping the footprint of the Java core small, especially if the new syntax is perceived as being important only to a "niche market".
An alternative approach was also discussed. Instead of introducing a new syntax into the Java language itself, preprocessors or integrated development environments (IDEs) could be developed to support multidimensional array syntax. These could support improved readability of programs for Grande applications without the need for a change to the core language.
Nevertheless, the multidimensional array syntax proposal will be submitted.
Joe Darcy reported on his work with Michael Philippsen on introducing a complex data type to Java. The goal is to make complex behave exactly like a primitive type. It would be implemented by translation to calls to methods in an associated complex class. There would also be a purely imaginary data type. Careful description of the semantics and implementation of complex is quite difficult. Thus far, the basic operations have been defined. All cases where these touch the current language spec have been identified and documented. Work on specification of the elementary functions is in progress. Proper definition of branch cuts and corner cases will be a challenge. Good reference implementations may be difficult to construct. Dave Hare, who has considerable experience with the development of complex functions in Maple, has agreed to participate in this project.
Tim Lindholm described the changes in the elementary functions that have been included in Java 1.3 as a result of discussions in the Numerics Working Group. Previously, the behavior of the elementary functions was specified to be those results produced by a straightforward translation of fdlibm to Java. In practice, this specification was being ignored. The new specification is as follows.
Sun's JDK 1.3 contains fdlibm in C. Versions for the Intel processor that use hardware sine and cosine have been developed and will be introduced in JDK 1.3. These perform their own argument reduction, since the x86 functions are only valid for arguments whose size is less than 263. The existing C implementation in StrictMath is fairly well behaved, but requires some care as compiler optimizations can break reproducibility. Thus, the C version introduces some fragility in implementations. It is expected that a version of fdlibm in pure Java, based on those developed by John Brophy at VNI, will be incorporated into java.lang.StrictMath at some point in the future. Such a version would be immediately portable to implementations with conformant floating-point, reducing fragility (and probably also footprint). A pure Java version would probably also, in the short term, reduce performance somewhat, but given the looser definition of java.lang.Math, there is less pressure on java.lang.StrictMath to yield top performance.
The Scimark benchmark of NIST was briefly discussed. Several suggested that Scimark should include tests to insure that the correct answer is being produced. These should take the form of simple "sanity checks" to catch gross defects in the Java environment (or blatant cheating). It was agreed that such checks should not have the aim of verifying conformance of the Java platform to relevant specifications.
The following additional issues were discussed.
Ron Boisvert, NIST,email@example.com
John Caron, Unidata,firstname.lastname@example.org
Dimitri Chiriaev, Sun,email@example.com
Cliff Click, Sun
Joe Darcy, Sun,firstname.lastname@example.org
Dave Hare, Waterloo Maple,email@example.com
Tim Lindholm, Sun,firstname.lastname@example.org
Mikel Lujan, Univ. Manchester,email@example.com
Sam Midkiff, IBM,firstname.lastname@example.org
Jose Moreira, IBM,email@example.com
Michael Philippsen, Univ. Karlsruhe,firstname.lastname@example.org
Roldan Pozo, NIST,email@example.com
Bill Pugh, Univ. Maryland,firstname.lastname@example.org
Joel Welling, Pittsburgh Supercomputing Center,email@example.com
The following people sent their regrets at their inability to attend.
John Brophy, Visual Numerics
Sid Chatterjee, Univ. North Carolina