Subject: minutes of JGMPG meeting

From: Vladimir Getov <[email-masked]>
Date: Fri, 2 Jul 1999 13:12:21 +0100 (BST)

Hi all,

I enclose the minutes of our first meeting below. Two important questions
were discussed by e-mail together with the draft-minutes:

1. The name of the MPI-like API - MPJ was chosen by most of those present
at the first meeting in SF.

2. A reference implementation for MPJ - It appears that we'll be working
on both a wrapper and a pure-Java versions.
	- wrapper MPJ - NPAC, Sun High Performance Computing, and
	University of Westminster have shown interest so far.
	- pure-Java MPJ - NPAC and Brigham Young University would be
	willing to work on this one.

Of course, it would be most advantageous to have at least one reference 
MPJ implementation ready by SC'99. Who are the interested parties to 
volunteer and invest time and efforts in this? Please e-mail about your
views and interest to participate.

Regards,
	-Vladimir

----------------------------------------------------------------------

                            Minutes of Meeting

                          Java Grande Forum (JGF)  
                    Message Passing Working Group (MPWG)
                             June 14, 1999
                         Sir Francis Drake Hotel
                            San Francisco, CA

Attendee List:

   (BC)  Bryan Carpenter        [email-masked]
   (GC)  George Crawford III    [email-masked]
   (RF)  Richard Frost          [email-masked]
   (VG)  Vladimir Getov         [email-masked]
   (SH)  Siamak Hassanzadeh     [email-masked]
   (GJ)  Glenn Judd             [email-masked]
   (DM)  Doug MacDonald         [email-masked]
   (PM)  Piyush Mehrotra        [email-masked]
   (ES)  Eric Sharakan          [email-masked]
   (MS)  Marc Snir              [email-masked]
   (MT)  Mary Thomas            [email-masked]
   (MW)  Martin Westhead        [email-masked]

After a short discussion of the final agenda the following items were
covered:

1. Introduction - 1:35pm PST

VG gave a brief overview of the recent developments and the current
status of the Message-Passing group. The group is a community effort 
within the frame of the JavaGrande Forum activities. The aim of the 
group is to provide an environment for discussion and collaboration in 
the research and development of portable message-passing frameworks and
corresponding APIs for the Java programming language. Important current
objectives of the group are 

- the development of an MPI-like API for Java;

- research into O-O Java-centric message-passing environments;

- performance evaluation and comparisons between different frameworks
  and implementations.

2. Java + MPI - 1:45pm 

MS gave a historic overview of MPI, the MPI Forum, and the standardization
process. The MPI Forum has been standardizing mostly on the basis of
existing practice with clear, perceived need and broad participation and
consensus from the beginning. The process was agreed formally and covers
the legal requirements, the voting procedure, as well as the editing and 
maintenance of the documents. In principle, MPI can grow (recent
examples being MPI-IO and the C++ bindings) but there has to be a
perceived need for significant community and, in general, the process is
not a simple one. MS then moved on to the MPI for Java topic with several 
important questions including "Is there a customer need?", "Is there
support from most (big) vendors?", etc. The underlying philosophy of MPI
is different from the Java philosophy and therefore the development of
Java-centric message passing is an interesting area for research and
development.

VG pointed out that there is a growing user interest in providing
message passing from Java. This includes supercomputing centers,
national labs, NASA, and other organizations, but this is still far from
the availability of application codes using Java+MPI.

2:00pm PST - At this point SH and MS had to leave and the discussion 
continued without them.

RF confirmed user interest at NPACI. BC stressed the interest of many
universities who would like to use Java+MPI in education.

The group decided not to submit the draft specification as a proposed 
standard MPI binding until or unless there is substantial vendor support.
However, we will keep the API as close as possible to the C++ bindings 
described in MPI-2, where Java language support or performance issues do
not require us to do otherwise. Considered the Java community process as
a possible alternative or supplemental standardization route.

3. Java-centric message passing - 2:15pm

The group felt that it is appropriate to continue with this issue which
was partially covered by MS in his presentation. PM commented that there
seem to be two somewhat divergent approaches to Java message passing:  
The first approach being to produce an API which is very similar to MPI,
and the second being a ground-up design. The first approach was chosen 
as a first quick solution by the group (see also the position document
JGF-TR-3) for two reasons:

1 - The majority of members present seemed more interested in the first
approach than the second.  

2 - There seems to be little consensus on where to begin the second 
approach which obviously requires more research at this stage. Several 
possible O-O approaches were mentioned including intra-JVM message 
passing, inter-JVM message passing, and VIA-based frameworks. GC 
mentioned that there is ongoing research at MSU in addition to the
efforts at MPISoftTech.

4. Draft specification of Java binding for MPI

4.1. Procedure for editing the draft document - 2:30pm

The group agreed that the editing will mostly be done by e-mail using
the web-sites at

http://www.npac.syr.edu/projects/java-mpi/
and
http://notch.cs.byu.edu/javampi/BindingIssues.html

In order to be more efficient in our e-mail discussion and editing it
was agreed that a proper reference (section + page + paragraph) to the 
current draft document should always be given. The group also felt that
an appropriate copyright for the specification document should be
arranged.

*** Action item -> BC and VG *** Investigate suitable copyright options
with JavaGrande or NPAC being the first choice.

4.2. The name - 3:00pm

After short discussion the group decided to use JMP or MPJ as the
official name of the MPI-like API for Java.

The group then took a coffee break.

4.3. Discussion - Open issues - 3:30pm

GJ presented the status of the current open issues with comments and
corrections from the others present as follows.

Datatypes
---------

There was a great deal of discussion regarding the use of both 
primitive and derived MPI datatypes. 

As the use of primitive data types in Java is redundant (due to the 
strongly typed nature of Java as well as reflection) there was a desire
to do away with them. There was also a desire to keep them in order to 
keep the API closer to traditional MPI. The need of a primitive complex
type was also discussed.

Support for MPI derived datatypes was also discussed. The argument for 
supporting these in the API centered on performance that would be lost
that could not gained by Java object support.

There was general support for including the ability to send and receive
Java objects in the API. The group discussed the tradeoff of API size 
with respect to the choice of overloaded communication methods vs. 
datatype parameter as a type-passing mechanism.

Single value support
--------------------

There was also a great deal of discussion about the support for single 
values in sends, recvs, bcasts, etc. in the API. The current API requires
arrays to always be sent and received. The motivation for single value 
support is that it simplifies user code. The counterargument is that it
complicates the API and implementation.

The exact solution of this problem is closely linked to the resolution 
of datatype support.

Mismatched communication types
------------------------------

There was some discussion about the semantics of methods that were 
passed arguments with mismatched types (e.g. a send where the sender 
sends floats and the receiver receives ints). As this can be detected 
in Java, there was some desire to require throwing exceptions in this 
case. There was also a view that throwing exceptions in this case 
should be allowed, but not required.

Multi-dimensional arrays
------------------------

There seemed to be a general view that these could be supported as an 
array of Java objects provided that they could be supported in an 
efficient manner.

User defined operations
-----------------------

There was general consensus that the issue of user defined operations 
needed further investigation before group discussion.

Interoperation with native MPI
------------------------------

There was some discussion about to what degree (if any) explicit 
support for interoperability with native MPI should be included.

MPI-2 support
-------------

There was some desire to include MPI-2 functionality in the API. There
seemed to be general support for inclusion of at least some MPI-2 
functionality, but only after MPI-1 functionality was first defined.

DM suggested that client/server functionality be included in the open
issues. The discussion also covered the issue of whether an Java+MPI
process is a JVM/Java native executable instance or a Java thread; 
tradeoff of MPI-like semantics vs. possible class reloading penalty.
Further discussions focused on the need to avoid Java's serialization
penalty where possible, to determine object size without serializing it 
as well as whether to support error handling on the Java exception
model.

The group decided to use instance variables and subclassing for the
functionality handled in MPI by communicator attributes.

*** Action item -> ALL *** Complete the specification document (final
draft) by SC'99. Discuss the chances (resources, time-scale, etc.) to 
have (at least one) Reference Implementation ready at the same time.

5. Performance evaluation - 5:00pm

VG reported that there is a growing number of parallel benchmark codes 
written in Java, using an MPI-like binding. This effort involves using 
and further developing these benchmarks for validation, evaluation, and 
comparison of MPI-like environments for Java. The codes currently 
available include:

 - A test suite for MPI-like bindings for Java which covers all 128
   MPI-1 functions. This task was completed at NPAC, but needs further
   updating in line with the draft specification document.

   RF suggested the translation into Java of another test benchmark -
   mpptest, which is available as part of the MPICH distribution.

 - Low-level message-passing benchmarks, which we have used to evaluate
   our existing prototype bindings on different platforms. Important
   issues here are both methodology and evaluation guidelines in order 
   to ensure reproducibility, sound interpretation, and comparative 
   analysis of performance results.  Some of the participating 
   organizations in this work are Brigham Young University, Emory 
   University, NPAC, University of Portsmouth, University of Westminster,
   and others.

   It was agreed that int and double are the most appropriate and
   important data types for the low-level tests.

 - Draft Java and MPI-like versions of the NAS Parallel Benchmarks IS,
   EP, and FT have been developed as a result of collaboration between
   San Diego Supercomputer Center and University of Westminster. Because
   of technical problems (lack of equipment for electronic presentations) 
   MT couldn't show results on up to 128 nodes IBM SP-2 at SDSC.

   NASA-Ames have recently allocated resources to join and lead the
   completion of a full set of NPB kernels in Java-MPI. This work is
   also part of the JavaGrande Benchmarking activities.

6. Date and place of next meeting - 5:30pm.

The next working group meeting was provisionally scheduled for end of
September or beginning of October in Syracuse.

The meeting was adjourned at 5:40pm PST.

---

From: Richard Frost <[email-masked]>
Date: Wed, 4 Aug 1999 10:34:29 -0700 (PDT)

Hi,

The Twelfth International Workshop on Languages and Compilers for
Parallel Computing is just getting under way here.  The program kicks
off with 3 papers on high-performance issues in Java.  The home page is
   http://www-cse.ucsd.edu/users/ferrante/lcpc.html
and the program along with online copies of the papers are at
   http://www-cse.ucsd.edu/users/ferrante/progwpap.html

Enjoy,
Richard F.

---

From: [email-masked] (Nik Shaylor)
Date: Mon, 09 Aug 1999 17:21:04 -0700

The answer to why I have been lurking around JG for the last year may become
clearer now that the project I have been working on is finally being made
public. I still cannot comment on it until the actual release, but if you
are going to HotChips you might like to hear Marc Tremblay talk about it in
session 8 on Tuesday.

I would be very interested to hear back from anyone who attends.

Kind Regards,

Nik

http://www.sun.com/microelectronics/MAJC/
http://www.hotchips.org