thoughts on a java reference implementation for mpj

22 April 2023 [email protected]

Thoughts on a Java Reference Implementation for MPJ

Mark Baker*, Bryan Carpenter

*University of Portsmouth

Florida State University

IPDPS, Cancun, Mexico – 5th May 2000

http://www.dcs.port.ac.uk/~mab/Talks/


Contents

Introduction Some design decisions An overview of the architecture

Process creation and monitoring The MPJ daemon Handling aborts and failures MPJ device

Conclusions and future work


Introduction The Message-Passing Working Group of the

Java Grande Forum was formed in late 1998 as a response to the appearance of several prototype Java bindings for MPI-like libraries.

An initial draft for a common API specification was distributed at Supercomputing '98.

Since then the working group has met in San Francisco and Syracuse.

The present API is now called MPJ.


Introduction No complete implementation of the draft

specification. mpiJava, is moving towards the “standard”. The new version (1.2) of the software

supports direct communication of objects via object serialization,

Version 1.3 of mpiJava will implement the new API.

The mpiJava wrappers rely on the availability of platform-dependent native MPI implementation for the target computer.


Introduction While this is a reasonable basis in many cases, the

approach has some disadvantages. The 2-stage installation procedure – get and build

native MPI then install and match the Java wrappers – tedious/off-putting to new users.

On several occasions we saw conflicts between the JVM environment and the native MPI runtime behaviour. The situation has improved, and mpiJava now runs on various combinations of JVM and MPI implementation.

This strategy simply conflicts with the ethos of Java – write-once-run-anywhere software is the order of the day.


MPJ – the Next Generation of Message Passing in Java,

An MPJ reference implementation could be implemented as: Java wrappers to a native MPI implementation, Pure Java, Principally in Java – with a few simple native

methods to optimize operations (like marshalling arrays of primitive elements) that are difficult to do efficiently in Java.

We are aiming at pure Java to provide an implementation of MPJ that is maximally portable and that hopefully requires the minimum amount of support effort.


Benefits of a pure Java implementation of MPJ

Highly portable. Assumes only a Java development environment.

Performance: moderate. May need JNI inserts for marshalling arrays. Network speed limited by Java sockets.

Good for education/evaluation. Vendors provide wrappers to native

MPI for ultimate performance?


Design Criteria for the MPJ Environment Need an infrastructure to support

groups of distributed processes: Resource discovery, Communications, Handle failure, Spawn processes on hosts.


Resource discovery

Technically, Jini discovery and lookup seems an obvious choice.

Daemons register with lookup services.

A “hosts file” may still guide the search for hosts, if preferred.


Communication base Maybe, some day, Java VIA?? For now sockets are the only

portable option. RMI surely too slow.


Handling “Partial Failures”

Need to overcome: When a network connection breaks, The host system goes down, The JVM running the remote MPJ task halts for some

other reason (e.g., occurrence of a Java exception), The program that initiated the MPJ job is killed. Unexpected termination of any particular MPJ job. Concurrent tasks associated with other MPJ jobs

should be unaffected, even if they were initiated by the same daemon.

All processes associated with the particular job must shut down within some (preferably short) interval of time cleanly.


Handling “Partial Failures” A useable MPJ implementation

must deal with unexpected process termination or network failure, without leaving orphan processes, or leaking other resources.

Could reinvent protocols to deal with these situations, but Jini provides a ready-made framework (or, at least, a set of concepts).


Handling failures with Jini

If any slave dies, client generates a Jini distributed event, MPIAbort – all slaves are notified and all processes killed.

In case of other failures (network failure, death of client, death of controlling daemon, …) client leases on slaves expire in a fixed time, and processes are killed.


Integration of Jini and MPI

Provides a natural Java framework for parallel computing with the powerful fault tolerance and dynamic characteristics of Jini combined with proven parallel computing functionality and performance of MPI


MPJ - Implementation In the initial reference implementation we

will use Jini technology to facilitate location of remote MPJ daemons and to provide a framework for the required fault-tolerance.

This choice rests on our guess that in the medium-to-long-term Jini will be a ubiquitous component in Java installations.

Hence using the Jini paradigms from the start should eventually help inter-working and compatibility between our software and other systems.


Acquiring compute slaves through Jini


MPJ We envisage that a user will download a jar-

file of MPJ library classes onto machines that may host parallel jobs, and install a daemon on those machines – technically by registering an activatable object with an rmid daemon.

Parallel java codes are compiled on one host. An mpjrun program invoked on that host

transparently loads the user's class files into JVMs created on remote hosts by the MPJ daemons, and the parallel job starts.


MPJ - Implementation In the short-to-medium-term – before

Jini software is widely installed – we might have to provide a “lite” version of MPJ that is unbundled from Jini.

Designing for Jini protocols should, nevertheless, have a beneficial influence on overall robustness and maintainability.

Use of Jini implies use of RMI for various management functions.


Mpjrun myproggy –np 4

Mpj Deamon

rmid

http server

Slave 1 Slave 2 Slave 3

Slave 4

Host


MPJ – Implementation Some assumptions that have a bearing on the

organization of the MPJ daemon: stdout (and stderr) streams from all tasks in an MPJ

job are merged non-deterministically and copied to the stdout of the process that initiates the job.

No guarantees are made about other IO operations - these are system dependent.

Rudimentary support for global checkpointing and restarting of interrupted jobs may be quite useful, although checkpointing would not happen without explicit invocation in the user-level code, or that restarting would happen automatically.


MPJ – Implementation The role of the MPJ daemons and their associated

infrastructure is to provide an environment consisting of a group of processes with the user-code loaded and running in a reliable way.

The process group is reliable in the sense that no partial failures should be visible to higher levels of the MPJ implementation or the user code.

We will use Jini leasing to provide fault tolerance –clearly no software technology can guarantee the absence of total failures, where the whole MPJ job dies at essentially the same time.


MPJ - Implementation Once a reliable cocoon of user processes

has been created through negotiation with the daemons, we have to establish connectivity.

In the reference implementation this will be based on Java sockets.

Recently there has been interest in producing Java bindings to VIA - eventually this may provide a better platform on which to implement MPI, but for now sockets are the only realistic, portable option.


MPJ – Implementation Between the socket API and the MPJ API there will

be an intermediate “MPJ device” level – modelled on the Abstract Device Interface (ADI) of MPICH.

Although the role is slightly different here - we do not really anticipate a need for multiple platform-specific implementations - this still seems like a good layer of abstraction to have in our design.

The API is actually not modelled in detail on the MPICH device, but the level of operations is similar (based on isend/irecv/waitany calls).


Layers of an MPJ Reference Implementation

High Level MPI

Base Level MPI

MPJ Device Level

Java Socket and Thread API

Process Creation and Monitoring

Collective Operations

Process TopologiesAll pt-to-pt modes

Groups

Communicators

Datatypes

Isend, irecv, waitany, …

Physical PIDs

Contexts & Tags

Byte vector data All-to-all TCP Connect

Input Handler Threads

Synchronised methods, wait, notify…

MPJ Daemon

Lookup, Leasing (Jini)

Exec java MPJLoader

Serializable objects


MPJ - Conclusions On-going effort (NSF proposal +

volunteer help). Collaboration to define exact MPJ

interface – consisting of other Java MP system developers.

Work at the moment is based around the development of the low-level MPJ device and exploring the functionality of Jini.

thoughts on a java reference implementation for mpj

Documents