%Studies of Integration and Optimization of Interpreted
%and Compiled Languages"
%aiming at interpreted (Java) Front Ends to high performance
%runtime in spirit of MATLAB/APL/HPF Interpreter we once built.
%section C,

\setlength{\textheight}{8.0in}
\section*{C. Project Description}
\setcounter{page}{1}
\setlength{\baselineskip}{0.21in}

\subsection*{C-1. Motivation of the proposed work}

Tremendous advances in microprocessor performance and
networking technology in the past
decades has produced the following scenario:
a personal computer today delivers higher performance than a
mainframe could do 20 years ago;
a vast sum of accessible computing power exists world wide.

Many consequences result from this scenario.
Although the debate over compiler vs interpreter
led to a focus for scientific computing in 
compilation about two decades ago,
the fact that an interpreted program runs fast today than a compiled
program ran 20 years ago suggests that the use of interpretation
technology may be revisited.
Besides the popularity of Perl, Tcl, and Python, etc., this evidence
is best manifested by the overwhelming success of Java
programming language, which is largely due to
its underlying interpreted nature.

\vspace{3mm}
Nevertheless, it remains a fact that interpretation is slower than
compilation-execution model within the same hardware technology. Thus,
a trend is to merge (integrate) the two technologies, as exampled by
JIT compiler in Java virtual machine, built-in computational
functions in MATLAB, and as well as an earlier instance --- interpreted
front-end supported by data parallel runtime in *LISP on CM2.
Parallel computing research has in fact shown the importance of relative
coarse grain units such as array primitives in HPF and they are naturally
supported by interpretive front ends.

Another important trend is the growing availability of excellent
distributed computing software aimed at web applications --- this includes
Java language support as well as sophisticated servers such as Jeeves and
Jigsaw. We have suggested that this provides good infrastructure on which
to build scientific computing environments that combine user productivity
and high performance execution \cite{Fox:95a}. 
As part of a set of studies of high end
computing ten years from now (the so called Petaflop studies), we proposed
the hybrid environment shown in Figure \ref{meta} which 
links a sophisticated interpreted problem solving environment to a
machine specific optimized runtime \cite{gcf:4}. In this project, we focus on a
small part of this environment --- what are the key issues
raised by hybrid interpreted/compiled environments to support computational
science.

\begin{figure}
\vspace*{0.2in}
\centerline{\psfig{figure=meta.ps,height=3.0in,width=4.5in}}
\caption{A Software Structure}
\label{meta}
\vspace*{0.2in}
\end{figure}

We intend to base our implementations on adapting infrastructure developed
for parallel Fortran (HPF) to a Java based environment.
We are encouraged by the recent meetings
(http://www.npac.syr.edu/projects/javaforcse) at Supercomputing'96 and
Syracuse. There several papers suggested Java can offer a combination of an
attractive object oriented language, high performance compilers,
and interpreted applet mode.

However our research will focus on the general issues of hybrid (compiled
and interpreted) environments using the Java based system as a particular
exampler. As well as native compilers, we will also integrate Just in Time
(JIT) concepts as they have shown already dramatic performance increases
including more than an order of magnitude on the Linpack benchmark.

%objective for the period and expected significance
\subsection*{C-2. Objective and expected significance}

The objectives of this research include:
\begin{itemize}
\item
  Identify issues in optimal integration of interpretation
  and compilation techniques for parallel language systems.
\item
  Study the impact of these issues on performance for scientific
  and engineering applications.
\item
  Develop a set of technologies that aim at a high performance
  language system with interpreted (Java) front end supported by
  compiled parallel runtime for solving scientific and engineering
  problems.
\end{itemize}

\vspace{3mm}
\noindent
The significance of the proposed activity may be observed in
the following facets.
\begin{itemize}
\item
  While the effectiveness of interpreted languages on
  text processing tasks (or in general, $O(n)$ algorithms)
  is well accepted,
  how it can best help (or can not help at all) 
  scientific and engineering applications, in the context of
  contemporary computer technologies, is not well understood.

  While the higher performance of compiled programs over interpreted
  counterparts is well known, the inconvenience (and inefficiency !)
  of \\
   \hspace*{0.3in} {\tt edit-compile-link-run-crash-start-it-all-over-again} \\
  process is also commonly recognized.

  This research addresses the
  potentials of bringing the benefit of both technologies together
  in a contemporary setting.
\item
  Compilation and interpretation technologies are actually
  merging, as seen in JIT compiler and graphics runtime support in Java
  system, but this is happening in an {\em ad hoc} way, which does not consider the
special constraints of parallel computing and science and engineering
applications.
\item
  While issues in parallel processing with compiled code have been
  studied extensively, not much is known as to how large scale
  parallel processing may benefit from an interpreted environment,
  which has obvious advantages for users.
\item
  As we have described \cite{gcf:3}, Java naturally links (data parallel) time
  stepped simulations with large scale event driven object based systems.
\end{itemize}

%outline general plan of work, design of activities, methods, etc
\subsection*{C-3. Proposed Research and Experimental System}

We intend to build our research on top of a set of experiments using an
experimental system which will allow us to examine different ways of
integrating compilation and interpretation techniques. We introduce,
as in Figure \ref{overview}, a new virtual machine (II/CVM or Integrated
Intepreted/Compiled VM) which can be thought of as generalizing (to data
parallelism) and focusing (to scientific computing) the successful Java VM.
This hybrid virtual machine is fed by a {\em frame processor} or compiler
(somewhat analogous to javac for the Java VM) called II/CVM compiler.

\begin{itemize}
\item
The {\em frame processor} converts the application program into an  
intermediate form, and
performs certain analysis, and possible restructuring, in addition to
syntax and semantics checking. The result will be a partially ordered
set of {\em interpretive frames}.  
\item
Under supervision of the virtual machine/scheduler, the actions 
specified in a frame may be performed in one of the
three ways.
  \begin{itemize}
  \item
  Executed by an {\em interpretive module} directly.
  \item
  Some precompiled {\em computational library} function is invoked
  locally to accomplish the task; this function may be executed
  sequentially or in parallel.
  \item
  The frame is sent to some {\em registered remote system}, which
  will get the work done, once again either sequentially or in
  parallel.
  \end{itemize}
\item
Necessary data flow coordination must be observed using appropriate
mechanisms around the common {\em data region}.
\item
Relation between the interpretive frames and source code is
well documented internally for diagnostic and debugging purpose.
This will use web information technology including linked databases.
\end{itemize}
The distinction between {\em local processor} and
{\em registered remote system} would be application dependent,
a machine on the same local area network may be considered
local or remote for different situations.

We distinguish fine grain parallelism (threads or data parallelism) 
within the local data region and typical coarse grain parallelism coming
from metaproblems. As we are implementing in separate research (WebFlow),
web technology can naturally implement coarse grain parallelism using
networks of Java servers (Jeeves, Jigsaw) and emerging concepts such as
Javabeans, \cite{dual96}, \cite{gcf:3}. These issues are interesting but not the subject of this
proposal.

\begin{figure}
\centerline{\psfig{figure=overview.eps,height=3.5in,width=5.0in}}
\caption{Architecture overview of a target system}
\label{overview}
\end{figure}

\subsubsection*{C-3.1. Component descriptions}

In what follows, we'll give a brief introduction to each of
the components in the system. This introduction is not supposed to
be a complete description of either the system or components. It
serves as an outline on possible issues or techniques that one may
encounter or employ
when trying to construct such a system. It's also not our intention to
deal with all the issues raised here in subsequent research, or
try to incorporate all known techniques in a system. Rather,
the research will be concentrated on identifying and evaluating
those key issues and techniques which when integrated together properly
constitute an optimal hybrid language system.

\subsubsection*{C-3.1.1. II/CVM compiler}

The function of the II/CVM compiler (or frame processor)
is to generate a partially ordered set of
frames for the virtual machine to execute. It will be composed of the 
following parts:
\begin{list}{$\bullet$}{%
  \setlength{\leftmargin}{0.2in}%
  \setlength{\itemsep}{0.1in}%
  \setlength{\parsep}{0.0in}}
\item
Language front-end
\item
Program analyzer/restructurer
\item
Interpretive frame generator
\item
Coordination interface
\end{list}
We propose the following features in each part.

\paragraph{Language front-end}

The language front-end is similar to that in a conventional
compiler\cite{Aho86}. It will perform syntax and semantics checking
on input programs, and construct an intermediate representation of the
source code.

The intermediate representation may be some lower level language or
even a set of highly structured data
items, recording the information in the source program for efficient
manipulation later in the frame processor. The design and
implementation of the language front-end will make use of research
and development results from the PCRC project conducted
in NPAC, Syracuse University, in particular, the HPF front-end \cite{Li96}.  

\paragraph{Program analyzer/restructurer}

The program analyzer/restructurer is used to obtain control flow and data flow
information from the intermediate representation of the source
program, and prepare things necessary for frame generator. Its main 
purpose is to {\em identify} and {\em organize} the 
parallelism in the program.

Both task parallelism and data parallelism may be exploited. While we
are not emphasizing, in this effort, fine-tuned loop analysis techniques 
that aim at parallel execution of a loop, we'll concentrate on 
discovering coarse-grained task units that can be independently
processed by either local or remote computational runtimes. Fine
grain data parallelism will be handled by the runtime system.

Parallelism in program can be derived either explicitly or implicitly.
For example, the explicit thread mechanism in 
Java language provides a simple yet 
effective way for expressing
task parallelism, and an array of threads is effectively equivalent to
the {\tt FORALL} construct as in HPF. Recent progress in HPF 
project\cite{Li97} helps us understand more about data parallel processing. 
An experimental work on ``High Performance Java'' conducted in NPAC
has also provided us some insight on parallel execution of Java programs,
\cite{dbc:1}.

On the other hand, techniques developed in parallelizing compiler,
particularly interprocedural and  data flow and dependence analysis related 
methods\cite{M:Hall}, \cite{Zim90}, \cite{Ban93}, may be used to explore 
implicit parallelism among chunks of code segments.  

Aside from this, pattern matching methods will be used to
recognize some special frames which correspond to pre-compiled
computational library functions, though maybe executed sequentially. 
This will be addressed more deeply in
the section on the computational library.

\paragraph{Interpretive frame generator}

An {\em interpretive frame} is a machine-independent task
description.  We do not understand yet exactly
how this will be implemented, but
a typical form of it will be a type of 
data package associated with a name of function
that has been implemented in the pre-compiled runtime.

The machine-independent feature is needed by the execution mechanism,
since a frame may be executed somewhere else in Internet. Like Java bytecode, 
frames on
different machine should be the same, so that the task can be
dispatched onto different resources.
Unlike Jave bytecode, the granulity of the frames may vary
significantly.  The execution expressed by a
frame possibly ranges from a
simple scalar assignment statement to a complicated computational procedure. 
This allows the potential power of pre-compiled computational library to be
fully exploited.

Dependence relation among frames
will be maintained in terms of a partially ordered set.
As we described earlier, parallel activities are distributed over
local interpretive module, local runtime library, and remote
runtime libraries. The dependence relation is used by scheduler
to dispatch frames at proper times.

\paragraph{Coordination interface}

The coordination interface refers to both the interface between the
frame processor and scheduler,  and the interface between the
programmer and frame processor.

The simplest form of coordinating interface may be, just like Java
language, an intermediate file, which is generated by the frame
processor and then interpreted and debugged on the virtual machine.

A more ambitious design is that the user may have more interactive
interface with the system. This may includes a programming
editing environment, communications between the environment with the
interpreter and the communication manager directly. Therefore it is
possible for a more user-friendly environment that supports things 
like program
tracing, error reporting or even letting user dynamically interfere
with the system scheduler.

\subsubsection*{C-3.1.2. Scheduler}

The scheduler module is aimed at management of the set of interpretive frames
generated by the frame processor,
determination of  the execution modes of them \cite{wen:4}, and coordination
of
the execution sequence. As mentioned earlier, a frame may be executed
in one of the three distinct ways: locally interpreted by 
{\em interpretive module}, locally executed by an invocation to a
{\em local runtime} function, or sent to some {\em registered
remote system}, which has specific computational
facilities, for execution.
When doing the computation, the scheduler will monitor the execution of the
interpretive frames, and return the results back to the II/CVM compiler,
for the purpose of interactive interface to the users.

The execution by local runtime or remote runtime may be {\em sequential}
 or {\em in parallel}. We emphasis both because {\em sequential} execution
in this context is also meaningful. For one thing, it's pre-compiled,
which presumably delivers higher performance than interpretation. For
another, some components of the problem, perhaps because of their
small size, may not
be suitable for parallel execution. This way, we still can
make use of them.

Making use of remote computing resources on the Internet presents much more 
complicated problems. Many research and development 
projects are aimed at this direction. Indeed,
with rapid growth of Internet, all the computer servers on the Internet
form a super-parallel computer system around the globe. And
each day, there are hundreds of computers added into the picture.
Millions of connected computers collectively deliver a vast amount 
of CPU cycles every second, which is certainly underutilized nowadays.
Effectively making use of this global
computing ability for scientific computing is many people's 
dream \cite{wen:14}. 

However as we have emphasized, this proposal is aimed at the use of web
infrastructure for the hybrid support of the fine grain synchronization
and optimization issues for scientific environments. The scheduler through
the communication manager will link to coarse grain computational systems
that aim to support web based metacomputing. These we assume will be
layered on top of the work we proposed here.

\vspace{3mm}
There are many interesting issues in this area, such as
resource management, task migration, security, and fault tolerance, etc,
where we will limit ourselves to a very simple strategy,
 since these issues are not our focus in this proposed effort.  

More specifically, our resource management will be simply based
on {\em registration}. A frame will only be sent to {\em registered
remote server}. Further,  the functionalities of those remote
servers are limited to pre-compiled scientific and engineering libraries. 
The remote servers will not talk to each other. There will be no
fault tolerance mechanism built in the system. They are assumed
to be reliable.

Thus, a simple, static {\em resource bank} is adequate for 
the scheduler to determine where to dispath a frame.

\subsubsection*{C-3.1.3. Interpretive module}

The interpretive module in the system is a functional unit to execute
``small'' frames.

Basically, three kinds of frames will be generated by the frame
processor of the system. The scheduler will let them invoke remote
computation resources, the computational library and the interpreter
respectively. The interpretive module usually will handle the
computation in the source program which can not be {\em formulated}
as a call to runtime, either locally or remotely.

The implementation of this module is relatively easy. A set of
procedures will be enough for the purpose. Given the availability
and popularity of Java, we may just use the corresponding part in Java
virtual machine as the interpretive module in our system.

\subsubsection*{C-3.1.4. Computational library}

More generally, we may call it a {\em runtime library} with emphasis on
CPU intensive computation. The purpose of this module is two-fold:
efficient execution of compiled code as opposed to slower
interpretation for {\em well formed} program segments; parallel execution
of typical parallelizable subtasks in scientific and engineering applications.

As we know, library techniques have been
very successful in supporting compiled programming languages.
With existence of pre-compiled library functions, 
application developers
can focus on the application
problems and algorithms themselves. 

Libraries, existing as part of runtime, are also playing a very 
important role in interpreted systems. This is best exampled by
graphics capability built in Java virtual machine.
As part of our Darpa PCRC activity, we are building Java native class
interfaces to computational library we have built to support HPF
compilation. We expect many more such optimized libraries to become
available for the Java VM.

Over the past years, many different kinds of libraries have been
provided for scientific computing.
But most of them are developed for supporting compiled languages, namely,
they exist in the form of object code to be linked with caller's
object code.  This is the traditional way of providing
the library functions for computing. We will study the mechanisms
that efficiently link interpreters with the libraries in our integrated
system. 

Another critical aspect of our 
computational library is parallel computing support.
A parallel 
library should be a collection of high performance mathematical subroutines
used by application programmers to solve large problems
\cite{wen:15}, \cite{wen:18}.
From the II/CVM compiler, we will get a partially ordered set of
interpretive frames. While the parallelism among different frames is
seen by the scheduler, parallel library routines are aimed at 
exploiting parallelism within a frame. 

Another issue or opportunity brought up by the idea of integration of
interpreter and pre-compiled computational runtime support is that the
routines in the library may not only be some well-known scientific function,
such as solving a system of equations, etc. A routine may also correspond to
some typical program segment pattern. Identifying and formulating those
patterns will be part of our research agenda.

\subsubsection*{C-3.1.5. Communication manager}

As we have observed, there are two kinds of parallelism in the
system, task parallelism among different frames  and possible data
parallelism within a frame, each suitable for some
specific parallel processing applications, respectively. When the scheduler
module determines that there exists task parallelism in the interpretive
frames, and that especially some frames are needed to be sent out to
external systems,
the communication manager module comes into the play. It will keep
track of external resources and let the scheduler know when something
is finished.

The communication manager should talk to a counterpart in
registered remote server. As explained earlier, the communication manager
is important for a complete architecture but will not be a major focus for
this research.

\subsubsection*{C-3.1.6. Data region}

The data region is a memory space in the virtual machine 
which holds the global
data of the problem. It is initialized according to the problem size
when the program started.

Since the global data may be changed by the interpretive module, the
computational library and communication manager, synchronization method
for these three parts is needed here. For simplicity, message passing
method will be used and remote socket communication among process in UNIX system
will serve this purpose.

Some data will need to be moved between the data region and remote
memory locations in external system.  Communication channels will be built up
between Java virtual machine memory and other memory pages with 
message passing native classes. We have built an MPI interface to Java
which can be used here.

\subsubsection*{C-3.2. A three year research plan}

\begin{description}
\item[Year 1:] Environment setup   and experiment design.

The goal is to reach a design of a set of experiments on
key issues and techniques possibly involved in the hybrid
language system as described above.

The completion of the design is signified by a detailed
description of the experiments and establishment of
an effective environment that allows the experiments
to be conducted. Thus,
with the architecture proposed above on mind, we'll work on
collecting and testing various tools and infrastructure needed
for experiment and issue investigation, with emphasis on
integration of the tools. For instance, we may use Sun's Java
front-end generator {\tt JACK} to produce a front-end; we
may use Stanford's {\tt SUIF} package to serve as a basis for
program analysis; and our own {\tt PCRC} runtime may be
used as a major component of the computation library, etc.
Clearly, finding the most suitable tools and `gluing' them
together requires substantial research.

\item[Year 2:] Build initial system, conduct experiments and data  analysis.

The goal is to obtain some meaningful quantitative conclusions
on the impact of various issues and techniques on the performance
of typical scientific and engineering applications.

The detailed agenda will depend on the first year's work. But in general we'll
try to conduct the experiments along 
several different fronts. We will identify a few key benchmark problems of
appropriate intermediate complexity which can be run with several different
parameter choices. We can expect the tradeoff between interpretation and
compilation to be very sensitive to problem size.

In this second year, we expect to have several modules of the system of
Figure \ref{overview} operational but not yet a full integration.

\item[Year 3:] new idea testing and system integration.

The goal is to arrive at an operational system that
demonstrates merits of integration of interpretation and compilation
technologies. This system will be derived from the experimental
environment, but it may or may not be of the same architecture
or execution mechanism as we described in previous subsections.
Obviously findings during the first two years of research may
suggest new approaches that improve overall performance and
usability.

\end{description}

\subsubsection*{C-3.3. International collaboration}

Substantial collaboration among NPAC at Syracuse University, USA, and
Computer Science Department of Peking University, China, and 
Computer Science Department of Harbin Institute of Technology, China
will be a distinctive feature of our working plan. This is enabled
by our successful collaborative activities in both research
and education areas during past two years.

Since arrival of Dr. Xiaoming Li at NPAC as a visiting scholar
in January, 1995, who then was a professor in Computer Science
Department of Harbin Institute of Technology and now is a professor
in Computer Science Department of Peking University, NPAC has been
engaged in several significant and highly visible activities
with those two universities and other Chinese institutes, including:

\begin{list}{-}{%
  \setlength{\leftmargin}{0.2in}}
\item
In summer of 1995 and 1996, NPAC director, Geoffrey Fox and senior project
manager Don Leskiw were invited to visit China. During these trips,
they gave talks on various topics ranging from traditional
HPCC and contemporary web technology in nine Chinese universities
and research institutes, including Peking University, Tsinghua University,
Beijing University of Aeronautics and Astronautics, Beijing University
of Post and Telecommunication, Harbin Institute of Technology.
Zhejiang University, Northwest University, Northwest Polytechnical
University, and Institute of Computing Technology. These visits uncovered
great interests in collaboration in basic research.
\item
Started from March and ended in July of 1996, NPAC conducted an
Experimental Internet Based Computational Science Education Program.
Five graduate students from Harbin Institute of Technology participated
in the program. Course materials and instructions were delivered by
an NPAC instructor to China via Internet on a weekly basis. Students
also submitted their homework and raised questions back to NPAC via the 
Internet. This program caused a sensation in Chinese media. Almost
all major newspapers and TV stations reported it. Upon completion,
all students expressed very positive opinions about the program. 
\item
Correspondingly, NPAC received a delegation of ``Pan Deng''
Programme (a national programme sponsored by Commission of Science
and Technology of China) in December of 1995, a delegation from
a key national software lab of China in February of 1996, 
Professor Zheng Weimin of Tsinghua University in August of 1996, 
and a delegation of 863 Programme in November of 1996.
\item
Also, coordinated by Dr. Xiaoming Li, a group in Harbin Institute
of Technology, a group in Peking University, and NPAC Parallel
Software Systems group have collaboratively developed a
quality public domain HPF front-end, and a joint HPF compiler effort
is ongoing.
\end{list}

From the above substantial activities, we have established
a solid base for further collaboration with Chinese researchers.
Inviting Dr. Xiaoming Li as an `official' participant of this project,
who will be visiting NPAC every summer, will strengthen this 
collaboration. In fact, a group of faculty members and
graduate students has been formed in his Peking university and a
similar project is being simultaneously proposed to Chinese NSF. 

\vspace{3mm}
Graduated from Stevens Institute of Technology in 1986,
Dr. Xiaoming Li is an active computer scientist in China.
He has published three books, more than 40 technical papers,
and led several sponsored projects, in parallel processing,
computer architecture, artificial intelligence, as well as
graph theory.
Awarded many grants by various Chinese agencies, he is also 
a Fellow of Chinese Computer Federation and a member
of Advisory Committee for Higher Education in Computer
    Science, appointed by the Education Commission of China.
He also served as program committee chair of 1991 International 
Conference for Young Computer Scientists, Beijing, China,
and program committee chair of the First National Symposium for
     Young Reliability Professionals, Qinhuang Dao, China.

We value the collaboration with Dr. Xiaoming Li, and believe
his participation in this project adds significantly to its
quality.

\subsection*{C-4. Related work}

We'll first summarize other people's work in related areas such
as {\em interpreter}, {\em compiler}, and {\em parallel runtime}
in the context of Java programming language, followed by a
review of the applicant's other related activities and research
results.

\subsubsection*{Other related research topics}
There was active research in the early 70's, as to whether a language would be
best executed in interpreted or compiled form. People had well understood
and agreed on the advantages and disadvantages of both.
Reference \cite{j:lee} presents a typical analysis at that time.
The basic conclusion was that interpreter was too slow to be
widely useful.

As microprocessors and personal computers became popular in
late 70's and early 80's, use of an interpreter was
once again favored by some people and applications.
Reference \cite{t:mcintire} and \cite{p:klint}
promoted the use of interpreters and discussed techniques employed
in construction of interpreters. Since then, more interpretive
language systems have been built. Among them, there are the popular
BASIC, Perl, etc., which are still in widespread use.

Nevertheless, the compilation-execution paradigm 
was still a main stream technology in
language processing due to its continuously improved performance and
introduction of tools and environments that help program development
process. Relatively speaking, we have seen much more progress and advancement
in compiler technology than in interpreter technology during past 15-20
years. This is evidenced by vast amount of literatures on compilers, in
contrast to a little on interpreters during those years.

The popularization of World Wide Web and advent of Java programming
language \cite{java:1} have injected new energy into interpretation
technology. Besides its traditional advantages, interpretation has
also proved
its value in cross-platform executability and security \cite{java:3}.
This development has already motivated some dedicated research
in interpreters such as project Rocky being conducted in
University of Washington \cite{t:romer}.

\vspace{3mm}
There is substantial research on optimizing Java both in
academia and industry, including industry leaders such as Sun and
Microsoft. Many issues are being explored, we note

\begin{list}{-}{%
   \setlength{\leftmargin}{0.2in}}
\item
\underline{Optimizing Java compilers}
  \begin{trivlist}
  \item
   IBM is developing optimizing Java compiler that produces
   binary code for IBM machine directly (reported by Susan Flynn Hummel 
   of IBM at Workshop on Java for Scientific Computing, Dec., 1996)
  \end{trivlist}
\item
\underline{Just in Time compilers}
  \begin{trivlist}
  \item
  {\tt Kaffe} system by Tim Wilkinson,
  http://www.tjwassoc.demon.co.uk/kaffe/faq.htm
  \end{trivlist}
\item
\underline{Optimization and restructuring of bytecode generated by {\em javac}}
  \begin{trivlist}
  \item
  Rice University, reported by Zoran Budimlic of Rice at the Workshop on
  Java for Scientific Computing, Dec., 1996.
  \item
  Rochester University, reported by Wei Li at the Workshop on
  Java for Scientific Computing, Dec., 1996.
  \end{trivlist}
\item
\underline{Parallel execution of Java program by making connection between
Java} \\
    \underline{and well established message passing systems}
  \begin{trivlist}
  \item
  {\tt JavaPVM} from Georgia Tech.
     This is an interface written using Java native methods capability
     which allows Java applications to use PVM facility.

   http://www.isye.gatech.edu/chmsr/JavaPVM/
  \item
    {\tt JPVM} from University of Virginia.
     This is a PVM-like library of object classes implemented in and
     for use with Java.

   http://www.cs.virginia.edu/~ajfzj/jpvm.html
  \item
    {\tt HPJava} from Syracuse University. This is an experimental
    work demonstrated at Supercomputing'96, which links Java with
    MPI.

   http://www.npac.syr.edu/user/gcf/hpjava.html
  \end{trivlist}
\item
\underline{Java source restructuring}
  \begin{trivlist}
  \item
  {\tt Javar} from Indiana University.
     This is a parallelizer for Java programs, see

   http://www.extreme.indiana.edu/hpjava/
  \end{trivlist}
\item
  \underline{Parallel interpretation of bytecode}
  \begin{trivlist}
  \item
  IBM JVM, released in spring 1996, an implementation of JVM on
     shared memory architectures.
  \item
  UIUC, newly started a project aiming at parallel interpretation
  of Java bytecode (private communication.)
  \end{trivlist}
\end{list}
We believe that this other work confirms the importance of our proposed
research activity. However we believe that we have identified many issues
where substantial research is still needed and to which we can make
meaningful contribution.

\subsubsection*{Applicant's related work}

\noindent
Fox has worked on parallel programming environments for the last 15 years
with the early focus
being message passing, \cite{gcf:1}, \cite{pcw}. 

Since 1987 he has collaborated first with Ken Kennedy
and then others, on parallel high level languages-especially Fortran. This
work was largely part of
Fox's activity in CRPC (The Center of Research in Parallel Computation)
which played a major
role in the development of HPF with prototype compilers and community
language definition \cite{gcf:2}.
This led a major project from ARPA to develop in
collaboration with Rice a
prototype High Performance Fortran (Fortran90D) compiler, including a High
Performance
Fortran interpreter that was demonstrated at Supercomputing'93, 
\cite{hpf:1}, \cite{hpfi}.
This early HPF compiler was licensed by the Portland Group
whose resultant
commercial product is quite highly regarded. The prototype HPF interpreter
was our first study of
some of the issues we wish to follow up in this proposal. 

We believe Web technology is now
advanced enough that we can actually build and study sophisticated
interpreters (linked to
compilers) for science and engineering computation which were prohibitively
expensive in 1994
when we decided not to proceed further with our HPF interpreter. In fact
the MOVIE system built
by Furmanski and used as basis of HPF interpreter, lovingly constructed
many of the capabilities
now offered as pervasive robust technology by the Web (and especially
Java). 

Fox is now the PI
of another major Darpa project, the parallel compiler runtime consortium
(PCRC), which is
developing a common runtime for high performance (data parallel) languages
including Fortran
C++ and Java. This project is a collaboration with Cooperating Systems,
Florida, Harvard,
Indiana, Maryland, Rochester, Rice and Texas. 

Fox has recently focused on looking at the
opportunities for using Web technologies to improve the infrastructure and
functionality of
scientific and engineering programming environments, \cite{dual96},
\cite{gcf:3}. In
particular , Fox was the Chair of Workshop on Java for Scientific Computing
held in Syracuse,
Dec., 1996, and he will be co-chairing the ACM 1997 Workshop on Java for
Science and
Engineering Computation to be held in Las Vegas, Nevada, June 21, 1997.
Some of the ideas
discussed here have come from discussion in the PetaFlop initiative where a
set of meetings in
which Fox played an active role, has discussed the software and hardware
issues of possible
parallel systems 10 years from now, \cite{gcf:4}. Related research has
built a Web based
virtual programming laboratory which was used in a parallel computing class
last semester and is
being tried out in Cornell's Virtual Workshop at this time, \cite{Din97}.
This technology supports HPF and MPI in a user friendly environment and we
believe that interpreted
environments - as we propose to investigate here - are very promising for
improving HPCC education and training. 

