JPVM is a PVM-like library of object classes implemented in and
for use with the Java Programming language. PVM is a popular message
passing interface used in numerous heterogeneous hardware environments
ranging from distributed memory parallel machines to networks of
workstations. Java is the popular object oriented programming language from
Sun Microsystems that has become a hot-spot of development on the Web.
JPVM, thus, is the combination of both - ease of programming inherited
from Java, high performance through parallelism inherited from PVM.
Why a Java PVM?
The reasons against are obvious - Java programs suffer
from poor performance, running more than 10 times slower than C and
Fortran counterparts in a number of tests I ran on simple numerical
kernels. Why then would anyone want to do parallel programming in
Java? The answer for me lies in a combination of issues including
the difficulty of programming - parallel programming in particular,
the increasing gap between CPU and communications performance,
and the increasing availability of idle workstations.
- Developing PVM programs is typically not an easy undertaking for
non-toy problems. The available language bindings for PVM (i.e.,
Fortran, C, and even C++) don't make matters any easier. Java has
been found to be easy to learn and scalable to complex programming
problems, and thus might help avoid some of the incidental
complexity in PVM programming, and allow the programmer to concentrate
on the inherent complexity - there's enough of that to go around.
- CPU performance is improving at a much quicker rate than either i/o
or network performance - the result: programs aren't CPU bound any
more (of course there are many exceptions to this, but the trend is
there). Thus, perhaps the additional expense of Java isn't so grave
after all. This is yet to be seen, but it's my conjecture.
- Even given the fact that JPVM programs will consume much more processor
power than similar compiled codes, the ever increasing availability of
idle workstations is cause for optimism. A JPVM program will consume
more CPU power, but the power will be there to be consumed. What the
JPVM program will consume less of (hopefully) is programmer
time and effort.
Is JPVM interoperable with standard PVM?
The answer (sadly) is no. JPVM is a completely separate, non-interoperable
implementation. I didn't take the time to reverse-engineer PVM and
make JPVM interoperable because JPVM is really just an experimental
toy for me at this point - a rough prototype that can be used to
experiment with parallel programming in Java on a network of
workstations.
On the other side of the non-interoperability coin, JPVM supports
a number of great features that simply aren't available in standard
PVM. For example:
- JPVM messages are never forwarded through daemons
before being delivered directly to the destination task. In
PVM, such unnecessary message forwarding is inherent in the
design of the default, and only truly stable communication
mechanism.
- The JPVM library is thread safe. Multiple Java threads of control
can cooperate inside a single JPVM task, allowing, for example, nice
efficient JPVM multithreaded servers to be coded with ease.
- JPVM decouples communication endpoints from active processing
entities. In standard PVM, every task has a single communication
endpoint identified by its Task Id. In JPVM, a new task id is
created within a process every time a new jpvmEnvironment
object is constructed. This allows the active processing entities in
a parallel program to be processes, threads (which can
communicate via messages in a location transparent manner),
or any combination of these, allowing advanced latency
hiding and load balancing techniques to be coded in a
straight-forward fashion.
Why not just Java bindings to the standard PVM library?
Java bindings to the standard PVM library are a great idea.
Such a tool would allow programmers with existing PVM applications
in a variety of languages to link in Java graphical user interface
front ends. In fact, such a library exists and is available:
JavaPVM.
This library uses the Java "native methods" functionality to
allow Java programs to access the standard PVM library.
The reason I didn't take this approach with JPVM is portability.
While Java and PVM are available on many systems, using native
methods restricts tasks to run only on systems where both
Java and PVM are supported. An important part of the JPVM concept involves
leveraging the portability of Java to make more types of PC and workstation
machines viable hosts for PVM tasks.
More Information?
A brief report about the interface, design, implementation, and
performance of JPVM is available in postscript form:
A smaller version of this report appeared at the
Java'98
poster session:
- Click here to download
raw postscript (~340 KB).
- Click here to download
PDF (~44 KB).
A paper by Narendar Yalamanchilli and William Cohen (of U. Alabama
Huntsville) describing performance measurements of JPVM (also appeared at
Java'98) is
available:
- Click here to download
raw postscript (~229 KB).
- Click here to download
PDF (~107 KB).
Where can I get JPVM?
The current version (v0.2.1) requires Java 1.1.
Recent updates...
- A race condition in pvm_recv was found and fixed by
Professor Thomas R. James of the Dept. of Mathematical Sciences
at Otterbein College. Many thanks to Professor James for finding
and sharing this important bug fix, which is incorporated in the
latest release (v0.2.1).
Older updates...
- Tested with kaffe 0.9.2.
- Daemon startup bug on windows machines is now fixed.
- The task spawn implementation was recently improved and
is now much quicker. Also, failed task creation no
longer locks up the system - the daemons will still talk
to one another and other applications will still run.
- The daemons now write their port to a file in /tmp (like
the standard PVM daemons) so you no longer need to specify
the local daemon port on the command line when running
apps.
- The spinning behavior exhibited by tasks blocked in
pvm_recv has been fixed - blocked processes will no
longer consume CPU cycles.
- Now tested with Java 1.1.
- Message passing performance greatly improved thanks to
object serialization.
JPVM questions, comments and problems should be directed to
Adam Ferrari,
ferrari@virginia.edu.
Additional Information About Java and PVM
ferrari@virginia.edu
Last update: ajf2j Mon Feb 1 13:37:25 EST 1999
