Minutes

Java Grande Numerics Working Group Meeting

June 5, 2000

San Francisco

 

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.

 

ACTION ITEMS

  1. Determine how the Java Grande Forum could be an official participant in the Java Community Process. (Boisvert, Lindholm)
  2. Notify the working group by email of the status of the fastfp JSR. Solicit participation in a possible experts group. (Boisvert)
  3. Decide whether to continue fastfp in the JCP 1.0 or JCP 2.0. (Moreira, Snir)
  4. Incorporate minor changes into the fastfp JSR as requested by Sun and resubmit. (Moreira, Snir)
  5. Decide whether to continue the multidimensional array API with the JCP 1.0 or to jump to 2.0. (Moreira, Pozo)
  6. Modify the multidimensional array API JSR to accommodate the requests of Sun and resubmit. (Moreira, Pozo)
  7. Finalize draft of the multidimensional array syntax JSR and circulate in the Java Grande Forum for comments. (Pozo and Moreira)
  8. Complete development of draft complex JSR and submit to Java Grande for further review. (Darcy, Philippsen, Hare)
  9. Complete preparation of fdlibm in Java for inclusion into java.lang.StrictMath. (Lindholm, Brophy)
  10. Add "sanity checks" on results to Scimark. (Pozo)

 

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:

  1. At initial submission
  2. Before the public draft
  3. At the end of the process

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

Actions

  1. Determine how the Java Grande Forum could be an official participant in the Java Community Process. (Boisvert, Lindholm)

 

Fastfp

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.

Actions

  1. Notify the working group by email of the status of the fastfp JSR. Solicit participation in a possible experts group. (Boisvert)
  2. Decide whether to continue fastfp in the JCP 1.0 or JCP 2.0. (Moreira, Snir)
  3. Incorporate minor changes into the fastfp JSR as requested by Sun and resubmit. (Moreira, Snir)

 

Array API

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.

  1. Sun doesn't like the name "array" for this package. (It is already in use.) They suggested "matrix", which would not be acceptable to the Working Group. The Group suggests "multiarray".
  2. Sun doesn't want dependencies between JSRs. Since references to array syntax is not critical in this JSR they will be removed.
  3. The JSR originally called for an extension to the Java Native Interface (JNI) to provide a method for extracting multidimensional array elements in a particular order. However, Sun does not want to make changes to JNI. Instead, extractor methods will be added to the proposed array API.

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.

Actions

  1. Decide whether to continue the multidimensional array API with the JCP 1.0 or to jump to 2.0. (Moreira, Pozo)
  2. Modify the multidimensional array API JSR to accommodate the requests of Sun and resubmit. (Moreira, Pozo)

 

Array Syntax

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.

Actions

  1. Finalize draft of the multidimensional array syntax JSR and circulate in the Java Grande Forum for comments. (Pozo and Moreira)

 

Complex Arithmetic

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.

Actions

  1. Complete development of draft complex JSR and submit to Java Grande for further review. (Darcy, Philippsen, Hare)

 

Elementary Functions

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.

Actions

  1. Complete preparation of fdlibm in Java for inclusion into java.lang.StrictMath. (Lindholm, Brophy)

 

Benchmarks

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.

Actions

  1. Add "sanity checks" on results to Scimark. (Pozo)

 

Additional Issues

The following additional issues were discussed.

  1. Multiprecision Class. Sid Chatterjee has just announced an implementation of Bailey's MP package in Java. It is available at http://www.cs.unc.edu/Research/HARPOON/mpjava/.
  2. Interval Class. Dimitri Chiriaev of Sun reported the inclusion of support for intervals in Sun's Fortran and C compilers. Work on developing an interval class for Java is to be started again this summer.
  3. IEEE Standard Functions. Joe Darcy reminded the group of his work in developing pure Java implementations of the IEEE standard functions that are not currently available in Java. (Note: these do not include methods for setting or examining IEEE flags or rounding modes.)
  4. IEEE Flags and Rounding Modes. Dave Hare of Waterloo Maple expressed the critical need for access to such facilities in pure Java. Maple is considering making extensive use of Java for a variety of reasons. However, Maple is also striving to be IEEE 754 compliant, so the lack of access to these IEEE features in Java is a significant, possibly insurmountable stumbling block.
  5. Another Matrix Package. Mikel Lujan of the University of Manchester reported that he is developing a new matrix package for Java with support for many types of matrices, such as dense, sparse, triangular, etc.

 

APPENDIX

Attendees

Ron Boisvert, NIST, boisvert@nist.gov

John Caron, Unidata, caron@ucar.edu

Dimitri Chiriaev, Sun, dmitri@eng.sun.com

Cliff Click, Sun

Joe Darcy, Sun, darcy@cs.berkeley.edu

Vladimir Getov

Dave Hare, Waterloo Maple, deghare@maplesoft.com

Tim Lindholm, Sun, lindholm@eng.sun.com

Mikel Lujan, Univ. Manchester, mlujan@cs.man.ac.uk

Sam Midkiff, IBM, smidkiff@us.ibm.com

Jose Moreira, IBM, jmoreira@us.ibm.com

Michael Philippsen, Univ. Karlsruhe, philipp@ira.uka.de

Roldan Pozo, NIST, pozo@nist.gov

Bill Pugh, Univ. Maryland, pugh@cs.umd.edu

Joel Welling, Pittsburgh Supercomputing Center, welling@psc.edu

The following people sent their regrets at their inability to attend.

John Brophy, Visual Numerics

Sid Chatterjee, Univ. North Carolina

Geoffrey Fox


Posted: 16 June 2000. Last change: 16 June 2000. Contact: boisvert@nist.gov.