Embed Size (px)
Citation preview
University of Alberta
AN ASSESSMENT OP JAVA/RMI FOR OBJEC~ OR~ENTED PARALLELSSM
by
Alberto Daniel Zubiri 0
A thesis submitted to the Faculty of Graduate Studies a d Research in partial fdfi l l- ment of the requirements for the degree of Master of Science.
Department of Computing Science
Edmonton, Alberta Fa11 1997
Nédional Library Bibliothèque nationale du Canada
Acquisitions and Acquisitions et Bibliograp hic Se~*ces senrices bibliographiques
The author has granted a non- exclusive licence aiiowing the National Lt'brary of Canada to reproduce, loan, âîstiîbutt or sd copies of this thesis m microfom, paper or electronic formats.
The author retains ownership of the copyright in this thesis. Neither the thesis nor substantial extracts firom it may be printed or otherwise reproduced without the author's permission.
L'auîeur a accord6 une licence non exclusive penne!ttant à la Biblioth&que nationale du Canada de reprodurre, mer, distri'buer ou vendre des copies de cette thèse sous la forme de microfichdfilm. de reproduction sur papier ou sur format électronique.
L'auteur CO-e la pfopneté du droit d'auteur qui protège cette thèse. Ni la thése ni des exûah substantiels de celle-ci ne doivent être imprimés ou autrement reproduits sans son
To rny Family
Abstract
Java is a relatively new object-oriented language that supports concurrency and net-
work programrning; two characteristics that make it an ided candidate for the drvt4-
oprnent of parallel applications using networks of workstations. The latest version of
the language incorporates a new form of communication between objects callecl Ilr -
mote Method Invocalion (RrCSI). This feature allows objects to transparently invoktb
methods across the network.
This t hesis explores the issues involved in automaticaily transforming sequent ial
ob je t -o r i en t4 prograrns written in Java into equivalent distributed prograins that
will run on a network of workstations and whose objects will transparently comriiii-
nicate by using the RMI system. The fwus is placed on how the features of tlw
language. the object-oriented technology used, and the parallelizations techrkp.2
applied can be cornbineci for the development of such distributed prograrns.
This thesis uncovers some hard problems that will need further research. Es-
ceptions, a feature that is common in many of today's laquages (e.g. C++ ). cari
seriously limit the amount of concumncy obtained by the use of asynchronous mes-
sages. The dynamic dispatching feature, common in many object-oriented langiiagw.
can becorne a problem for properly identifying the objects that need to be chaiigt4
when some other objects are placed in a different d d r e s s space. This thesis identifitbs
many of the problems introduceci by RMI. Solutions for most of these probienis artb
presented. However, given its performance, we conclude that the arnount of conipilvr
support needed to address ail these problems is too large compared with t h e benrfits
obtained by using the RMI system as the underlying communication paradigm of oiir
p d l e l i z i n g tool.
Acknowledgement s
First and foremost, I thank my wife, Adriana, for her love and care. Her uncondi-
tional support givrs me the confidence and strength necessary to tackle any task. 1
dso thank my family in Argentina for dl their understanding and encouragement.
Specially I want to thank my mom, Maria Eugenia, and my daci. Lito. For giviiig r t w
the life and for always letting me choose rny own way. Thanks also to my family-ici-
law, Coco. Zuny and Ceci for the the thousands of cmai ls that helped me to copb
with the distance.
1 also want to take this opportunity CO thank rny supervisors. Dr. Jonathiiii
Schaeffer and Dr. Ron Unrau, for their guidance and funding. The arnount of tirrit.
and effort they dedicated to me greatly improved my work. 1 am also grateful to Dr.
Duane Szafron and Dr. Xiaoling Sun for taking the time to read and comrnrnt oii
this thesis, and to Dr. Joe Culberson who cha i rd my thesis defense.
He1 p from rny colleagues in the Parailel Programming S ystems Research C; roii p.
is highly appreciated. I would also Like to thank to Diego and Liliana Novillo. and to
Andrea and Manuela Junghanns for dl their support, Company and friendship.
Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Scope of the Thcris . . . . . . . . . . . . . . . . . . . . . . . . . . . . : 5
1.3 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . - t
2 The Java Language 5
2.1 Design Goals . . . . . . . . . . . . . . . . . . - . . . . . . . . . . . . - .)
2.2 Language Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . s
2.3 The Java Platforni . . . . . . . , . . . - . . . . . . . . . . . . . . . . il!
2.4 Sumrnary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1
3 Remote Method Invocation 12
3.1 Introduction . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . 12
3.2 The RMI System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 RMI Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . - . . . . t !I
4 Object Serialization 20
4.1 Object SerializationinJava . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 The Serialization Process . . . . . . - . . . . . . . . . . . . . . . . . . 23
4.3 The Deseriaiization Procas . . . . , . . . . . . . . . . . . . . . . . . 26
4.4 Limitations . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . - . 27
5 Performance Evaluation 30
5.1 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . :! 1
5.2 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . :j:j
5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5
6 Inheritance 37
6.1 Inheritance and RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . :l;
6.2 Inherited Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . :IS
6.3 lnherited Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -11
6.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -12
7 Futures 44
7.1 FuturesinJava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5
7 1 . 1 Server Side Futures . . . . . . . . . . . . . . . . . . . . . . . . -16
7.1.2 Client Side Futures . . . . . . . . . . . . . . . . . . . . . . . . -17
7.1.3 Client Side Futures / Future Cornputes . . . . . . . . . . . . . -i!)
7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1
8 Collaborators 56
8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii . . 8.2 Collaborators and RMI . . . . . . . . . . . . . . . . . . . . . . . . . . - 1 4
8.3 The Translation Process . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.4 sumrnary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:l
9 Runtime System 64
. . . . . . . . . . . . . . . . . . . . . . . . 9.1 Prototype Runtime System r;ri
9.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
10 Related Work 73
10.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2HORB 76
10.3 JavaPVM and JPVM . . . . . . . . . . . . . . . . . . . . . . . . . . . $0 10.4 Voyager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S I
10.5 JavaParty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
10.6 Summary . . . . . . . . . . . . . . . . . . . - . . . . . . . . . . . . . SG
11 Conclusions
List of Tables
List of Figures
- 2.1 Java's Exception Handling Mechanism . . . . . . . . . . . . . . . . . I
3.1 RMIArchitecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . I;'i
3.2 RMI Example: Local Code . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 RM 1 Example: Server Code . . . . . . . . . . . . . . . . . . . . . . . 1 ï
3.4 RMI Example: Client Code . . . . . . . . . . . . . . . . . . . . . . . I S
4.1 WritingtoanObjectStrearn.. . . . . . . . . . . . . . . . . . . . . . 21
4.2 Reading from an Object Stream . . . . . . . . . . . . . . . . . . . . . -P) --
Fi. 1 Remote Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1
5.2 Elapsed Time Algori thm . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 SocketsIrnpIementation . . . . . . . . . . . . . . . . . . . . . . . . . :!?
6.1 Sensor Inheri tance Hierarchy . . . . . . . . . . . . . . . . . . . . . . . XI
6.2 Temperature Sensor Remote Intedace . . . . . . . . . . . . . . . . . . a!) 6.3 Local Use of TempSensor . . . . . . . . . . . . . . . . . . . . . . . . . 15:)
6.4 Use of TempSensor as a Remote Object . . . . . . . . . . . . . . . . . -10
6.5 Sensor Ciass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -1 1
6.6 Access to a Protected Attribute . . . . . . . . . . . . . . . . . . . . -1 1
6.7 Remote Access to a Protected Attribute . . . . . . . . . . . . . . . . 42
7.1 Future's Remote Interface . . . . , . . . . . . . . . . . . . . . . . . 46
7.2 Server Side Futures . . . . . . . . . . . . . . . . . . . . . . . . . -4 7
7.3 Code for Server Side Futures . . . . . . . . . . . . . . . . . . . . . . . -tS
1.4 Client Side Futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.5 Client Side Futures / Future Cornputes . . . . . . . . . . . . . . . . . r> i
7.6 Future's Code for Client Side Futures 1 Future Cornputes . . . . . . . 57
8.1 Temperature Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.2 Temperatun DispIay . . . . . . . . . . . . . . . . . . . . . . . . . . . 57'
8.3 Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.4 Collaborators Detect ion . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.5 Generic Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . 62
9.1 O bjectserver's Remote Interface . . . . . . . . . . . . . . . . . . . . . 65
9.2 The Runtime System Architecture. . . . . . . . . . . . . . . . . . . . 66
9.3 ObjectServer's lmplementation . . . . . . . . . . . . . . . . . . . . . 67
9.4 Hello World Application: Sequentid Venion . . . . . . . . . . . . . . 6s
9.5 Hello World Application: Paralle! Venion, Remote Interface . . . . . ti!)
9.6 Hello World Application: Paralle1 Version, Heilo Implementation . . . :O
9.7 He110 World Application: Parailel Version . . . . . . . . . . . . . . . . ï 1
-- 10.1 Computation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 a -I 10.2 PIComputat ion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I : )
0- 10.3 HORB Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . r
10.4 RemoteObjectCreationandRemoteMethodInvocationinVoyager. S?
10.5 JavaParty Code Translation . . . . . . . . . . . . . . . . . . . . . . . S.i
Chapter 1
Introduction
1.1 Motivation
Nowadays, the computing world is changing fiuter than cver; new computer systtbrrih
are deployed every day and the explosion of the World-Wide \Veb is changing t l i t b
way people do business. interact and communicate. Networks of workstatioris artb
common in many organizations. Moreover, as the price of computer hardware drops.
the computing power amilable in today's organizations continues to grow. A s t h
availability of low-cost, high-performance workstations continues to increase. t tierc* is
also a growing number of unused CPU cycles. Many efforts have b e n made to takt*
advanrage of this potential computing power by combining networks of workstations
to form powerful supercornputers. ln these networks, parallel applicatioi:~ can tw
developed to solve larger problems than before and to obtain increased performaiictn.
However. parallel programrning is a ditficult task that involves dealing witli rnariy
issues not present in sequential programming such as communication, synchroniza-
tion, non-deterministic program behavior and work distribution [SS96]. Furtherrnorv.
if the underlying parallel computer is a network of workstations, issues such aï nt-t-
work partitioning and network latency also need t~ be addressed.
A broad spectrum of parallel programrning toois have been developed to cope w i t h
the complexities of parallel programrniag. Those seeking the maximum perforniarirtb
prefer low-level code libraries that have a minimal amount of overhead. Examplr3
of these low-level tools include sockets and message passing libraries (such as P U 1
[SunSOj and MPI [MPIo.I]j. Programming with these libraries is a highly skillcd task.
The programmer is free to chose the best way of parallelizing t h e applicatioii. hut
is also responsi ble for explicitly handling the communication, synchronizat ion. and
many more low-level issues.
Many attempts have been made to alleviate the intrinsic cornplexity of paral-
le1 prograrnming mainly in the form of high-level pardlel programming tools and
environments that support parallel extensions to existing languages or necv paral-
le1 laquages. Examples of these environments are Enterprise [SS+93] and HeNC'E
[BD+93]. Parallel prograrnming environments allow the programmer to conceritratiD
on the algorithm's development rather than on the low-level details of the paral-
lelization (e.g. processor allocation, communication protocols, etc.) by providing th<.
programmer with an abstract model. The main disdvantage of these parallel prw
grarnming environments is the lack of flexibility when the structure imposed by th&
models differ frorn that of the application.
Since object-oriented technologies have been succaufully applied to develop brt trr
sequential applications. it is possible that rhose technologies would benefit t hr par-
alle1 applications' world. Object-oriented languages have been successfully usrd t~
implement powerful and flexible software systems. In the object-orienteci paracligni .
an object is a self-contained entity which has a private structure and a public inttsr-
face. An application implemented under this paradigm can be seen as a collection of
communicating objects which cooperate to obtain the desired result. These ot>jerts
communicate by exchanging messages according to their interfaces.
In the case of sequential execution, al1 the messages are exchanged in a fixecl
execution order which is directly derived frorn the statement order in the prograria
source. There is exactly one thread of control in which objects communicate. Thte
communication is performed synchronously while the thread of control is passcd t u
gether with each message sent from one object to another. However, if messages artb
sent asynchronously wi thout the accompanyiog thread of control, t hen the senclPr
may continue executing concurrently with the receiver of the message. This leads to
a model in which a program will be executed by several threads of control. Under tliis
model, an application is represented as a collection of concurrent ly execut ing object s
that communicate using message passing.
Tradi tional object-oriented Ianguages such as Smalltdk (GR831. Objective C [('ossti j
and C+ + [S t r9 l ] have been developed wit h special emphasis on software engintrriiir,
concepts such as reusability, encapsulation, inheritance and polymorphism. Little or
no attention has been paid to concurrency.
However, the idea of applying object-oriented techniques to the programming of
concurrent applications ha9 gained popularity in recent years. Severd object-oriented
languages have been created to deal with concurrency (e.g. Actors [AH87], POOL-T
[Ame87], HYBRID [Nies?]) and many existing laoguages have been extended to s u p
port it (e-g. ConcurrentSmalltalk [YTB'I], pC++ [BD+92]). In particular, amorig
the new languages recently created, Java [G JS961 supports concurrency and net wor k
programming which makes it an ideal candidate for the development of parallel ap-
plications using networks of workstations. Furt hermore, the latest version of t l it-
language incorporates a new form of communication cailed Remote Mefhod hr.oc(i -
tion ( R M I ) [RMISi]. This feature allows objects to transparently invoke mrtho<ls
across the network. Ideally, this will facilitate the developrnent of object-orientcd
paralle1 applications that will have their objects distributed throughout the nctwork.
Those objects will t ransparently cooperate regardless of their location by excharigi ng
messages, and a high degree of parallelism will be attained by using the procrssitig
power of the participating nodes.
1.2 Scope of the Thesis
This thesis addresses the issues involved in automaticaily distributing seqiicntid
object-oricnted programs written in Java by using a paraileiizing tool (e.g. paral-
lelizing compiler andior programming environment). The goal of such a tool is t o
translate sequential Java programs into equ ident disttihittd programs that will ruri
on a network of workstations and whose objects will transparently communicatr t ~ y
using the RMI system. In particular, the focus is placeci on how the featurcs of
the lanyage, the object-oriented technology used, and the parallelization techniquis
applied can be combined for the development of such distributecl programs.
While doing this work, several probtems were encountered that had a significant
impact on how to generate objet-oriented parailel applications. Each of the problenis
encountered is analyzed to determine its source, and possible solutions are e x p l o r d
While some problems are directly related to the Java/RMI design. ot hers are int rinsic-
to the object-oriented characteristics of the programs (e.g. problems due to inher-
itance and dynarnic dispatching); or to parallel computing (e.g. non-deterministir
program behavior ).
This thesis uncovers some hard problems that will need further research. Narnely.
it is shown how the use of exceptions, a feature that is common in many of today's
languages (e.g. C++), can seriously limit the arnount of concurrency obtained by
the use of asynchronous messages. A h , it shows how the dynamic dispatching fea-
ture, common in many object-oriented languages, c m become a problem for properly
identifying the objects that need to be changeci when some other objects are placed
in a different address space. RMI, in addition, p r e n t s many problems that can t~
addressed as discussed in this thesis. However, given its performance, we also cori-
clude that t he arnount of compiler support needed to address ail these problems is too
large compareci wit h the benefits obtained by using the RMI system as the unclerlyirig
communication paradigm of our parallelizing tool.
Other contributions of this thesir include: a performance evaluation of tht* RAI1
system, solutions to some RMI-related problems, and a prototype runtime systerii for
distribu ting Java programs.
1.3 Thesis Organizat ion
The rest of this thesis is organized as follows. Chapter 2 introduces the Java languagt*.
its design goals and its main features. Chapter 3 pnsents Remote Method Invocatiori
( RMI). Its main characteristics are discussed and an example is provided. In Chap ter
4. object seriaiization is explained in detail. Chaptrr 5 presents a performancr e d -
uation of RMI and object serialization. Chapter 6 shows how inheritance fits wit ti
the RMI system. The concept of futures is explained in Chapter 7 with a disciissiori
of different alternatives for implcmenting them in Java. Chapter 8 covers the topit-
of collaboraton. h prototype runtime system is described in Chapter 9 and relatc*d
work is presented in Chapter 10. Finally the conclusions of t his t hesis are presentmi
in Chapter 11.
Chapter 2
The Java Language
The Java programming language has its roots in a previous languagi? called Oak
[Eng97]. Oak was the main result of s research project started at Sun Microsysterns
Inc. around 1990 that targeted the development of software for embedded systenis
and consumer electronics devices. This project started with C++ as the progranirnitig
language. However, after many problems with C++, the development team decicli*tl
that they were better off creating an entirely new language and Oak was born.
After the introduction of Moeraic and the World Wide Web in 1993, the rrncarctt
project shifted direction and focused on the development of software systenis for
online multimedia. Oak was poditioned as a 'language-based operat ing systeni.- 1 t .;
source code was given away for free on the Internet. Before releasing the software or1
the Internet and after considering diffcrent names (such as Seon. Lyric. Prpptbr aiid
Silk) the name was changed to Java.
Then Netscape, which quickly became the most popular Web browser. niade a
cornmitment to support Java. After that, Java has becorne the preferred langtiage of
the Intemet community, and software written in Java can be seen everywhere.
2.1 Design Goals
Java's origins as a language for prograrnming consumer electronics, and the problciiis
faced with C++ in the beginning, contributed to set the following design goals for
Java (J095, GM961:
Simple, Object Oriented, and F'amiliar: The new language should he easy tu
learn so that programmen could become productive with little training. Evtw
though C++ proved to be unsuitable, Java was designed to look as close a..
possible to it. This dlowed C++ programmen to look at Java as something
farniliar and be productive in the language very quickly. To keep the languagrb
simple though, many complex features of C++ were omitted, such as operator
overloading, mu1 tiple inheritance, and extensive automat ic coercions. huto-
matic garbage collection was also included to simplify the pmgramming and
to avoid bugs due to storage management errors that were common in C++.
The language was made object oriented borrowing characteristics from ('++. Objective C. SmallTalk, Eiffel, and Cedar/Mesa.
Network-sawy: The Java language provides direct support for network prograiii-
ming with libraries that simplify the complexities of deaiing with differerit pro-
tocols such as TCPIIP. FTP and HTTP.
Robust and Secure: Software embedded in consumer electronics requires the higli-
est level of robustness. Java attains this with extensive compile-time and riiri-
time checkings and with language features that enforce heal t hy programniiiig
practico, such as exception handling (see Figure 2.1). There are no pointers
and the dynarnically allocated memory is automat icaily garbage collected. This
characteristic makes the software more robust and secure since applications art8
not allowed to manipulate addresaes to access data that they are not siippos~d
to. Also, the runtirne system provida extra validations to ensure that Java
systems are secure from extemal tampering.
Architecture Neutra1 and Portable: The need for running programs on differerit
hardware architectures (Le. different consumer electronics devices or di ffereii t
computen in an heterogeneous network), cailed for an architecture ne ut ral dt:-
sign. Java programs are compiled to an architectureindependent format, called
bytccodes, which can be run on any Java-enabled platform without modification
(this idea was borrowed from Smalltaik [GR83]). Java goes one s tep furt her h~
defining the sizes of the primitive data types and dso the behavior of arithmctic
on them (e.g. floats are always 32-bit IEEE 754 floating point numbers).
Interpreted: To run the same binary program on any hardware platform r i tho i i t
trV { // Code that may raise exceptions (via the throw statement). // Also. the block rnay be exitcd by a break. continue or return // statement.
1 catch(exception~ame e) {
// code that will handle the exceptions of type exception-name (or one // of its subtypes.
// This code is always excecuted regardless h w the try block was // uited. That Y, after the end of the try block, or a break. continue // or return staternent is reached, or after an exception is handled by a // catch block or after an exception is r a d and not handled.
1
Figure 2.1 : Java's Exception Handling Mechanism
recompiling, the bytecodes are interpreted and translatecl on the fiy to tht*
particular machine code suitable for the hardware the application is riinnirig
on.
High Performance: Performance is a key design issue t o any software system. Evwi
though Java is an interpreted language, high performance is still attainable I q
exploiting multithreading. native methods and JIT compilers. ' Multithreaded: Many applications today require the ability to have several t hings
going on at the sarne time. For example, a Web browser could be docvnloaclirig
a file and at the sarne time displaying a page with sounds and live video. Eacli
of these concurrent activities can be executed by a separate thread. Thrrads
are part of the Java language and m u l t i t h d i n g is built into every component
of the runtime systern (e-g. the garbage collecter runs in a separate low-priori ty
thread). System libraries are thrcad-sa fe and the language provides powverfd
t hread synchronization primitives.
Dynamic: Java is dynamic in the sense that it adapts to an evolving environmcnt. - -- - - - - - - - - -
'Just in time (JIT) compilcrs translate the bytecodes into machinede on the fiy for the platforrii where the application is running. If the same method W calleci again, the compiled version is i i w l
instead, thus improving performance.
Classes are Ioaded from different sources (even from the network) and linkrd
only when they are needed. Any object in Java can be queried about its class
and new instances of a class whose name is obtained at runtime can be dynarn-
ically created.
2.2 Language Features
The Java language features follow, to some extent, those found in the C/C++ lari-
guages (GM96j. However, some of the C/C++ features are not present in Java.
These include: typedefs, preprocessor, structures, unions, enums, free-standing ftinr-
tions, multiple inheritance, goto statements, operator overloading, au tomat ic c0t.r-
cions. and pointers. These features were omitted by the language designers in t h r i r
quest for an easy to use and robust language (e.g. automatic coercions can be t tw
source of bugs when the programmer is not fully aware of them).
The basic features incorporated into the language include primitive data types
(e.g. boolean, int, double, etc.), ari t hmetic and relational operators, scope mocli f i t m
(e.g. private, public, protected, etc.), arrays, strings, control flow and decision-niaking
staternents, and an exception handling mechanism. Among the advanced featiws
included in the language are:
Object-Oriented Features: Java is a truly object-oriented language in t h e serist*
that it supports objects, classes and inheritance as defined by Wegner [WegSï].
It also supports encapsulation, polymorphism, and dynarnic binding. In Java.
every class has exactly one parent (i.e. single inheritance) and bas a common
ancestor (i.e. Object). Classes are also abjects in Java. Parameters and returri
d u e s are always passed by reference. Abstract classes, interfaces and visi M i t y
modifiers (e.g. private. protected, etc.) are aiso supported. See [CM961 for a
complete reference on these topics.
Mernory Management and Garbage Collection: Memory management is veq-
simple in Java. New memory is ailocated with the new operator but, unlike in
C/C++, there is no delete operator. Dynamically ailocated mernory is aute
matically garbage collected. The garbage collecter runs in its own low-priorit-
thread, freeing storage and compacting the memory pool.
Integrated Thread Synchronization: The Java language provides direct sup-
port for threads. There is a Thread clsu and the language provides powerfd
synchronization primitives.
Interfaces: Since Java only supports single inheritance, an interface feature is pro-
vided. Interfaces allow Java to create the illusion of multiple inheri tance. A i l
interface is a contract that a class agrees to implement. Saying that a cLass
implements a particular interface means that it provides an implementation for
ail the methods declareci in the interface. Moreover, interfaces are data types
in Java, which means that instances of a class that implements a particiilar in-
terface c m be assigned to variabla of the interface type. Interfaces are iised to
specify functionality without specifying a specific implementation. A claïs cari
implement any number of interfaces and inheritance c m be applied to t hem. :\ri
interface can extend one or more interfaces, that is, interfaces support mtiltiplt*
in heri tance.
Packages : A package is a collection of classes that are related in some way. Evcbry
Java class belongs to a package. Classes for which a package is not spccifird
belong to the default package. The concept of package allows a programmer to
separate the classes into different modules. Java also provides scope moclifirrs
which can regulate the access based on the class' package.
Security: Security played a big role in the definition of the Java language and its
runtiiiie gstrtn. Aay appfication devefoped in Java is subject to four levels of
security (Ham96j:
1. Language and compiler: The lack of pointers in the language prrwrits
attacks made by the manipulation of addresses. Since the compiler dot*s
not dlocate memory, a potentiai hacker cannot infer any physical Iayoiit
by looking at a declaration. Moreover, there is no language construct t hat
permits a programmer to obtain the address of an object andior met hocl.
2. Bytecode verifier: To prevent attacks from hostile Java compilers, t h
runtime system subjects al1 code to a simple theorem prover that perfornis
some validations (e.g. it checks whether the code violates access restric-
tions and whether ail the instruction parameters have the correct type).
3. ClassLoader: Each class that is loaded from the network executes within
its own separate name space. Al1 the classes loaded from the local file
system share the same name space. When a c l a s references m o t her. the
referenced class is looked up first in the local name space. If not found. then
it is Iaoked up in the narne space of the referencing class. This prevents
code loaded from the network from "shadowingn a built-in class or a class
loaded from a different site.
4. Interface speciRc security: The Java networking package can bc confis-
ured to provide different levelsof security for the protocols that it interfacta
to (e.g. HTTP. FTP, etc.).
2.3 The Java Platform
Nowadays, maay different and usuaily incompatible platforms exist (e.g. Microsoft
Windows, Macintosh. OS/2, UN IX, etc.). Cenerally, applications developeû for «i i tb
platform do not run on another (at Ieast not without considerable effort).
Java introduces a new software platform that sits on top of any existing plat-
form (ICra961. This allows the deployment of applications that will run on atiy nia-
chine where the Java platform is implemented, without recompiling the source. Ewti
though there are many impiementations of the Java platform (Le. one for eaçli dif-
ferent héudware/OS), there is only one specification for this platform. This makes it
possible to develop the applications just once and run them everywhere. Two kinds
of programs cm be deployed on the Java Platfonn:
Applets: Java programs that need a browser to nin. These program are clown-
loaded from the network and run on the dient machine.
Applications: Stand-done Java programs. These programs do not require a browwr
to run and do not have a built-in downloading mechanism.
The Java Platform has two main components:
Java Virtual Machine: The Java Virtual Machine is an abstract cornputer that cari
be implemented (either in software or hardware) on top of any real cornputer.
Java Application Programming Interface (Java API): The Java API provides
a standard interface to applets and applications to the Java Virtual Machine
that is the same across ail the operating systems. The Java API can be furtht*r
divided into:
The Java Base API: Which provides the basic language, utilities, 110. ntbt-
work, GUI. and applet services.
The Java Standard Extension API: Which provides a framework to incor-
porate capabilities that are beyond the Java Base API (e.g. Java Entw-
prise, Java Commerce).
This chapter introduced the Java language. Its design goals and main feat ures w r t S
explained. The Java platfonn was aiso introduced. Java is an interpreted langiiagb
that among other features supports: tree single inheritance, interfaces (wit h rniilt iplr
inheritance), dynarnic dispatching, different scopes, threads and exception handling.
As we will see in the following chapters. some of these features will present sprcial
chalienges when t ry ing to au tomat ically parallelize sequential Java programs.
Chapter 3
Remote Method Invocation
3.1 Introduction
Distri buted systems require the existence of some form of communication betwmi
applications running in different address spaces. Java supports sockets as a g ~ n c r a l
form of communication between objects running on different virtcial machines ( cvh irh
could be running on the same or different hosts). Socket programming, howcvt-r.
is a demanding task since al1 the details of the communication have to be hanclltd
by the programmer. Before two applications can communicate using sockets. t l i t*
developer has to design protocols (i.e. which communication pattern the interact ions
will follow) and message formats (i.e. the structure of the transmi tted data). This is
a time-consuming and error-prone activity. Furthemore, once in place, protocols and
message formats are hard to change so the system becomes more dificult to mairit ah.
Starting with version 1.1. Java provided a new type of communication betwctw
objects called Rcmotc itlethod Invocation (RMI) [RMI97]. This new abst ract ioii pcr-
iiiiiu tlir drvetoprr to concentrate on the application development rat her t han t lit*
complexities of the communication process.
3.2 The RMI System
The RMI system is built on top of the socket mechanism and provides the seniaii-
tics of RPC ( Remote Procedure Call) [BN83] applied to distri buted object-orien tecl
systems. Even though the design of the RMI system is general enough to accornniij
date asynchronous messages, the current implementation only supports synchronotis
method calls. In the RMI model, a Remote Object is defined as one that implenients
some methods that can be called from a different Java Virtual Machine. ' A remote
method invocation is then the act of calling a method of a remote object defined in
a remote interface implemeated by this object. The syntax for invoking one of t hese
remote methods remains the sétme as the one used for a local d l . This character-
istic makes RMI easy to use because there is no new syntax to learn. alt hough t h t n
user still must be familiar with the concepts of remote objects and remote met hocl
invocations. The methods exported by a remote object are described by one or mortb
remote interfaces. Clients will see only what is defined in the remote interface of a
remote object. This implies that direct access to instance variables is not possiblr
with RMI (only methods and constants can be defined in a Java interface). Also. i t
implies that RMI cannot be used with static methods because the modifier static is
not ailowed in a rnethod declmtion inside an interface. Furthermore, since d l t h c e
methods in an interface are implicitly abstract and public (i.e. the rnodifiers private
and protuted are not allowed inside interfaces), ail the methods that will be callc*cl
remotely need to be public.
References to remote objects CM be returned as rnethod return values or used a..
parameters in any rnethod invocation. no matter whether the object that implemrnts
the method is local or remote. Any parameter or returned resuit in a remote metbot1
invocation that is not a remote object is passed by value. Remote objects are passrd
by reference.
For a client to invoke a remote method, it first has to get a reference to the rrb-
mote object. The RMI system provides a simple oame service. called the regist rg.
tfiat can be used for this purpose. The registry is a 'well-knownw remote objrc-t
whose responsibility is to map narnes t o remote objects. A common configuration
consists of a single ngistry for each host, but it is ako possible to have a registry
for each server process (either in the same or in a different virtual machine). Clients
can access the registry directly using the methods defined in the Registry interface
and the LocateRegistry clas. or using the URLbased methods provided by the claïs
java.rmi.Naming. The Registry interfsxe pmvides methods for lookup. binding. uri-
'Note that a nmote objec~ can still have local rnethods that can only be calied from objects that
rcside on the same virtual machine as rhe remotc object.
binding, rebinding and listing the contents of the registry. The LocateRegistry clnss
provides static methods that allow a program to retrieve a reference to a registry
given different parameters such as the host and port number.
Since there are more opportunities for failures in distributed systems (due to
network partitioning, routers dropping packets, etc.) than in local systems, clients
of a remote method invocation must be able to handle additional exceptions throwii
by the RMI system. Al1 t h e exceptions are subclasses of java.rmi.RernoteException.
Thus, every met hod declared in a remote interface must add java .mi. Remoteu<ception
to i ts throws clause. When an error occun, the RMI system t hrows a RemoteException.
However, the client may have little or no information for determining if the failiir~
happened before. during, or after the remote cal .
3.3 RMI Architecture
The RMI system is c o m p o d of three independent layen: the stub/skeletori Iaytbr.
the remote reference layer. and the trawport layer ( s e Figure 3 4 . Each layer corti-
municates directly only with the layer imrnediately above or below it. For evanipltb.
user programs (i.e. client and servers) only talk directly with the stubfskeleton 1ayt.r.
The boundaries between any two layers are defined by precise interfaces and p r o t t ~
cols. This m&es each layer independent of the next and, thus, replaceable by anothcr
implementation that adheres t o the proper interface and protocol. For example. t l i t *
current implementation of the transport layer is based on TCP sockets but this cari
be replaced by an implementation based on UDP sockets without affecting tht* otlicr
layers.
Figure 3.1 illustrates a client communicating with a server. Both objects rmicltm
on different virtual machina and the client invokes a remote method implemented hy
the server. The stubs and skeletons are automatically geneated by the RMI cornpilt*r
(rmic) from the remote interfaces. Clients interact with stub objects (proxies of thtb
remote object) that have exactly the same set of remote interfaces defined by th<.
remote object's class. Non-remote portions of the c l w hierarchy of t h e remote clash
are not included in the stub. Thus. only those methods declared in the remottb
interfaces can be called remotely.
I Virtual Machine 1 l l Virtual Machine 2 1
Figure 3.1: MI Architecture
A remote cal1 made by the client is handled by the stub which relays al1 th<-
invocations to the server via the reference layer. The remote reference laycr is irstrl
to abstract different semantics for an invocation (e-g. unicasting, mu1 ticasting. etc. ).
The reference layer uses the services of the transport layer for setting up connectioris
and remote object tracking. The skeleton at the server side receives the invocatioris
from the transport layer and makn the appropriate cdls to the remote object wliicli
executes the actual method catis. The return values are sent back to the client frorri
the server to the skeleton, then to the remote reference layer. from there to t h -
transport layer. up to the stub until finally reaching the caller.
The transmission of objects between different address spaces is done using .lava's
Object Seridization API which provides the functionality necessary t o pack and lin-
pack any arbitrary gaph of objects (see Chapter 4 for a more complete description ).
To illustrate how RMI is used. consider the code in Figure 3.1. There are two ciasst-5:
Sensor, which represents a physicai seosor of some sort; and MAIN. which is used CU
provide an entry point for the program. The program consists of creating an objcît
'In Java. al1 the pmgram begin executing the code contained in the main() method of thr
specificd class (i-e. MAIN in our example).
public clas sensor{ private boolean active;
public Sensor() { // Constructoi active = f a k ;
1 public void Activate() { // Callable method
active = true;
1 public void Deactivate() { // Callable method
active = false: 1
1
//-[ MAIN.jan jC public class MAIN {
public static void main(String argsu) { // Create and initialue a new Sensor object Sensor aSensor = ncw Sensor(); // Access it
Figure 3.2: RMI Example: Local Code
of type Sensor. cafled aSensor. and operating with it. The sensor is actiuated uvirlg
the method Activate() and, after doing something with it, the sensor is deactivatcd b~
Deactivate(). The code shown in Figure 3.2 a n s locally in a single virtual machine.
Figures 3.3 and 3.4 show the same progam tmoslated into a distributed wrsiori
using RMI. The original program ha9 ben split into a server which provides t h e
functionali ty of the sensor, and a client which uses the sensor. In this version. t hi.
client and the server run on different virtual machines.
Both server and client main() functions start by setting the system's security mari-
ager to an instance of RMISecurityManager. Since the code for the sti lbs and skr l r to i is
public interface SensorRl extends Remote { public void Activate() th rom RemoteException; public void Deactivate() th rows RemoteException;
1
//-[ Sensor.java 11, public class Sensor utends Unicast RemoteObjea im plements Sensor RI {
private bookan active;
public Sensor() t hrows Remotetrception { active = false;
1 public void Activate() t h r o m RemoteException {
. . I active = truc;
1 public void Deactivate() t hrows RemoteException {
. . . active = falx;
1 public static void main(String argsn) {
System.xtSecurityManagci(new RMISccurityManager());
trY { Registry registry = LocateRcgistry.getRegistry(); Sensr asensot = n m Sensor(); regist ry.rebind(" S ENS0 R" . asensoi);
) catch (Exception e) ( ~~stem.out.~rintln('*~ensor.main: an exception has occurred: " +
e.getM-ge()); e.printStackTrace(); S ystem.uit (-1);
1 System .out.println(" Remote Sensor ready." );
1 1
Figure 3.3: RMI Example: Server Code
//-[ MAIN.java ) public class MAIN {
public static void main(String argsu) { System.setSecurityManager(new RMISecurityManager());
trv ( Regist ry registry = LocateRegist ry.get Regi~tty(~ server Host N a me" ); SensorRl asensor = (SensorRI) regÛtry.lookup("SENSOR);
aSensor. Deactivate();
1 catch (Throwabk e) {
Systcm.out.println(" MAIN: an exception has ocurred: " +e.getMessage()); e.printStackTrace(); System .exit(-1);
1 1
1
Figure 3.4: RMI Example: Client Code
can potentially be loaded from the network, there must be a security manager in plaw
or an exception will be thrown. This security manager will ensure that the loacld
classes (i.e. the bytecodes that were brought into the virtual machine from the net-
work or from disk) adhere to the standard Java safety guarantees. Applications can
define their own security managers or use the provided RMISecurityManager. If tio
security manager is in place, no cllus can be loaded from the network.
The code for the server (see Figure 3.3) is divided into two files: SensorRl.java and
Sensor.Java. SensorRl is an interface used to declan which methods can be reniotcly
called by a client. The class Sensor implements the SensorRI interface. The main()
function in the server code just c rea ta an instance of sensor and registen it with the
local regis t ry.
The code for the d e n t (see Figure 3.4) shows how to remotely invoke rnethods
on the remote Sensor object. F i n t an object reference is obtained using t he rtBg-
istry. The registry contacted is the one that it is ~ n n i n g on the host where thc
server has been started. If the remote object (Le. the server) has not yet ben criL
ated and bound to the registry, the registry.lookup() cal1 will throw an exception (i-r.
java.rmi.NotBound6<ception). The reference obtained from the regist ry has t h e type of
the interface SensorRl rather than the class Sensor. This is because only those t hings
declared in the remote interface are seen frorn a difterent virtual machine. Once a ref-
erence has been obtained, the methods can be invoked using the normal Java syntax.
The calls are placed inside a try{) clause in order to deal with the remote exceptions
that can be thrown.
3.5 Discussion
Having explaineci the basic functionality of RMI, it is important to discuss the cl i f -
ferent issues involved in using it for the automatic pdle l iza t ion of sequential coclv.
A parallelizing compiler at a bare minimum should automate the generation of t l i t b
remote interfaces. Civen a class (through a modifier or using a graphical interfacr).
the compiler should be able to construct the remote interface by listing al1 t h e rndi -
ods of that class and adding the appropriate throm clauses for the remote excep tioris.
Also. RMI requires ail the metho& that will be cdled remotely (i.e. those thnt arc8
added to the remote interface) to be declared ap public. Thus. the compiler stioiild
verify (and change if necessary) the access privileges for each method that is ad<ied rt)
the remote interface. The compiler should also insert the appropriate try and catch
statements around each remote method invocation to automatically handle al1 t h .
exceptions t hrown by the RMI system.
Other issues where compiler support will be needed include: modifications to the
user code for handling access to instance and class variables. packing optimizations.
dynamic object creation, access to static methods, and asynchronous method calls.
These and other issues derived from them will be addressed in detail in subsequent
chapters.
Chapter 4
Ob ject Serialization
In distributed systems, data structures must be Battened before transmission ( i . ~ . .
they are put in a buffer for transmission according to a particular layout). t\t t h -
receiving end, the data structures are reconstructed from the Bat tened version. This
characteristic is not exclusive to object-orieatcd systems. In fact, the packing of
data structures also has to be performed in procedural languages (such as C) whrri
performing remote procedure cails (RPC) [BNM] or saving these structures to di&.
This process is known as 'packing", 'pickling", and 'marshaling". In Java it is ca11ed
Objcct Scrialixtion although. besides objects, it is also used to pack prirnitivtb data
t y p a -
Serialkat ion is an important issue for parailelizing applications. When an ohjeci
is to be sent across the network, its state rnust be saved at one end and restorc4
at the other end. If the object contains references to other objects, there are t ivu
possi bili ties: to pack the object and al1 the objects referenced from it (deep copy ). or
to pack only the original object (shailow copy). Clearly, using shallow copies is fastrr
than using deep copies. but sometimes a deep copy is needed to preserve prograrri
correctness (e-g. if the remote metbod accenws a nested reference, the referenccd
object should d s o be packed).
This chapter explains how object seridization is performed in Java. The foctis
is plwed on anaiyzing how the serialkation mechanisms affect the automatic parai-
lelization process.
FileOutputStream fos = new FikOutputStream("someefile"); ObjectOutputStream os = new ObjectOutputStrearn(fos); // writing of an object os.writeObject("This u a String object"); // writing of a primitive data type os.writelnt(100); os.flush();
Figure 4.1: Writing to an Object Stream
4.1 Object Serialization in Java
Object serialization provides the capability of storing and retrieving objects from a
stream. This means that the objecta can be made persistent (i.e. written to disk)
and, aiso, that the objects cm be transmitted through a communication channrl
(e.g. sockets). Thus. to scnalt:e an object coasists of writing to the stream al1 t l i ~
information needed to create an equivalent copy of the object a t a later time in t l i ~
same or a different place. The process of creating an equivalent object from t h e st rcani
is called dcsedi:ation. When seriaiizing an object, al1 the objects that are being
referenced by it are aiso s e r i a i i d to the stream in order to maintain the existirig
relationships among t hem (i.e. deep copy ).
The programmer can specify if a particular class is serializable or not (Le. if i t s
objects can be written to a stream). For example, a programmer might not want
to make a class serializable for security reasons. Classes whose supertype is not
serializable may still be serializable but have t o take responsibility for packing and
unpacking its parent's public, protected and package protected fields. This is only
possible though, if the supertype has a constmctor with no arguments (which will ht*
used to initiaiize the supertype's fields).
Normaily, objects are written to the stream using the writeObjut() method di-
clared in the ObjectOutput interface. Primitive data types are written using spccitic
methods declared in the Dataoutput interface such as writelnt(), writefloat(). ~t <-.
Figure 4.1 shows how a String object and an int are serialized.
The writeObject0 method handles the seriaiization of each object and al1 t h
objects referenced from it. The object, al1 the objects t hat are referenced froni i t .
1 FileInputStream f is = new FilelnputStream("some-file"); ObjectlnputStream is = new ObjectlnputStream(fis); // reading an object String aString = (String) is.readObject(); // reading a primitive data type int i = is.redlnt();
Figure 4.2: Reading frorn an Object Stream
and recunively any object that is being referenced from them, form the object's
graph. Objects are serialized at most once in a stream. If more references to ttw
same object are found while traveming the graph (i.e. when following the referrnccs )
they are encoded as a handle (i.e. an o&t inside the stream) to the already serializd
object. This allows for a very efficient representation which supports the cycles t l i i i t
can be present in an arbitrary object graph. Fields that are mark4 as transient or
static are not serialized/daeridized. This is because transient fields are not part of
the object's state by definition (Le. the keyword is used for that purpose). and static
fields are class variables (i.e. not part of the object's state but of its class).
Reading from a stream is dvo a straightforward process (see Figure -1.2). TIiv
method readObject0 is used to deserialize any arbitrary graph of objects and t lit.
methods readlnto, readFloat(), etc. are useâ to do~rialize the primitive data types.
The Object Setidiration API requires t ha t classes implement either the Serializ-
able or the Externalizable interface in order to serialize t h e objects of that class. For
classes chat implement Serializabk, al1 the information required to restore its objects
is automatically saved. In contrat , for classes that irnplement the Externalizable
interface, only the identity of the c l a s is automatically saved and the class is respon-
sible for saving and restoring its contents (by implementing the writeExternal() and
readExtonal() methods).
The Serializable interface is an empty interface (Le. there is no functionality to
implement) and it is used for the sole purpose of identifying a class as serializable. Iri
the early versions of the API, al1 classes were serializable by default. Later on. t tiis
default behavior was changed and only those classes explicitly declared to inipltbnimt
Serializable could have their state automatically saved to a stream. ' The rationale
behind this change in the design was twofoid. The first consideration had to do
with aecurity. Access to fields that are private, protected or package protected is
regulated by the Java runtime system. Once seriaiized, however, the byte strearii
can be accessed and changed by any object that has access to it. This violates the
privacy guaranteea of the language and could compromise the integrity of the Java
environment. Making classes not serializable by default prevents a programmer that
does not know about serialization from compromising the security and/or the intgrity
of the system because of his/her iack of knowledge.
The second reapon for the change in the design is to force the designer to think
about serialization before tagging a c l a s as seridizable. For example some fields maktb
sense only in the context where the object containing them was originally crratcd
(e.g. open sockets, open files, etc.). These fields should be marked as transient but
the programmer could neglect or forget to do so. In that case, if the classes w r t *
serializable by default the serialization procols could introduce incorrect behavior
into the system.
4.2 The Serialization Process
The ObjectOutputStream class irnplements the core of the serialization procas. This
class is responsible for keeping the state of the stream in which the objects are writttw
and also the state of the objects already serialized.
This class provides methods for writing d i k n t data types to the stream (c-g.
writelnto, writeLong(), etc.), and aiso for manipulating the stream (e.g. flush().
drain(), close(), etc.). Other methods provided by this class allow the traversal of
the objects that need to be seridized. Objects w saved on the stream together witli
the objects to which t hey refer (i.e. complete object graphs are saved). In particiilar
the writeObject() method is the one that implements the serialization of an objret
into a stream. Objects are serialized according to the following algorithm (OS961:
1. If the block-data buffer is not empty, its contents are written to the streaiii
'An extensive discuslion about this issue can be found in the archive for the RMI mailing l i ~ i
located at: http://cha~ubo.javasoft.c0m/emai1/nni-~~~~/. 2The stream can be buffered or unbuffered. Whcn using buffereâ mode. the data is put in t II#.
and the buffer is reset.
2. If the object being serialized is null, writeObject() returns after putting nuIl on
the stream.
3. If the object was previously written to the strearn, its handle is writ ten instead.
If the object had been replaceci, the handle for the replacement is written in-
stead. Then wiiteObject() returns. Note that the serialization routines arc
forced to keep track of which objects have dready b e n packed and which havr
been replaceci.
4. If the object being written is a Class, the corresponding ObjectStreamClass is
written, a handle is assigned for the c l w and writeObject() returns. An Object-
StreamClass describes a class that can be seriaiized to a stream or deserializd
from it. The ObjectStreamClau for a loaded clau can be found using a looktip
met hod provided by ObjectStieamClass.
5. If the object is an ObjectStreamClass, a class descriptor that includes narticb.
serialVersionUID ', and the lists of fields ordered by name and type is writ t w
to the strearn. A handle is assigned for this descriptor and the annotateClass()
met hod is called before writeObject() returns.
6. If the object is an instance of jsva.lang.String, the object is written in Cinivcrsal
Transfer Format (UTF) ' format and writeObjut() returns after assigning a
handle to the string.
7. If the object is an array, a recursit-c d i to deUbject( ) is used tu wr i t r tlir
ObjutStreamClass of the array. A handle is assigned for the array, and thcn t b r
length is written to the stream followed by each element of the Wray. Finally.
wtiteObject() returns.
8. If object replacement is enabled by a previous cal1 to enableReplaceObject(). t lit*
replaceObjut() method is cailed to allow subclassor to substitute an object. If
block-data buffer becore king written out to the stttam. 'The serialVersionUID is a number that identifies a particular version of a serialized clas. 'UTF is a "muiti-byte" cncoding format uscd for the storage and transmition of Unicmlr char-
acters (sce (Fla96. 20SZ09j).
the object is effectively substituted, the mapping between the original object
and its replacement is saved for later use in step 3. After the replacement, steps
2 through 7 are repeated for the new object. If the replacement object don not
correspond to the types handled in steps 2 through 7, the processing continues
at step 9 with this new object.
9. For regulat objects a recursive cd1 to writeObjut() is used to write the Object-
StreamClass of the object's class. A handle is created for this object.
!O. Finally. the contents of the object are written to the stream according to t h t b
following criteria:
The object is Serializable: The highest Serializable class is located. and for
this class and each derived class its fields are written. If the class ini-
plements a writeObject() rnethod, it is cded. If not, the defaultWrite0b-
ject() method is called instead. This method writes ail the non-static ancl
non-transient fields to the stream. Note that writeObject() can use default-
WriteObject() to write the state of the object and then write aclditiorial
in format ion.
The object is Externalizable: In this case the writeExternal() methoci is callml.
This method should save the entire state of the object and coordinatt* witli
its superclasses to save theit state.
The object is neither Seriaiizable nor Externalizable: When the objtart
is not Serializable or Externalizabk, a NotSerializableException is throm.
Even though it is not necessary to know the cornplete details of the serializatiorl
process in order to use it, some general understanding will help to better ut ilize i t . Specificdly, it is important to know the diRerence between Serializable objects and
Externalizable o n e . Also note that this is a generic serialization routine and. thtis.
it is very cornplex. Users could get better performance by writing their own ciistorti
serialization code.
4.3 The Deserialization Process
Object deserialization is implemented by the ObjectlnputStream class. This class is
responsible for maintaining the state of the stream and the objects already deseri-
alized. It provides methods for reading objects and primitive data types written by
ObjutOutputStrearn. The readObject() method is the one that implements the object
deserialization from the stream. Objects are deseridized from the stream according
to the following dgorithm (OS961:
1. If a block-data record is present on the stream, a BlockDataException is throwi
with the number of bytes that are available for reading.
2. If the object in the stream is null, nuIl is returned.
3. If the object in the stream is a handle to a previous object. t h e appropriatc*
object is returned from the set of known objects.
4. If the object is an instance of java.lang.String, then its UTF encoding is rmd
and the object and its handle are added ro the set of known objects. Then th<.
String is return.
S. If the object beiog read is a Class, the correspondiog ObjutStrearnClass descrip-
tor is read. The Class object is returned aftcr it is added with its handler to the
set of known objects.
6. If the object is an ObjectStreamClass, its name, serialVersionUID, and fields artD
read. Then, the object and its handle are added to the list of known object.~.
Following that. the rnethod rcsolveClau() ia used CO get a local class for this
descriptor (an exception is thrown if the class cannot be found). Finally. thch
ObjectStreamClau object is ret umed.
7. If the object is an array, its ObjectStreamClass and length are read. The arr-
is allocated and added with its handle Co the set of known objects. Thcn. eacli
element is read (according to its type) and assigneci to the array. Finally t h e
Wray is returned.
8. For any other object, its ObjectStreamClass is read from the stream and used to
retrieve a Iocal class. The ciass bas to be Serializable or Externalizable.
9. The class is instantiated, and the instance and its handle are added to the set
of known objects. Then, the contents are retrieved according to the following
cri teria:
Serializable objects: the neargument constructor for the non-serializable su-
pertype is calleci and each field is restored usiag the readObject() methocl
or the defaultReadOôject() method if necessary. If the version of the class
that wrote the stream and the version of the class that is reading th<%
stream dif€er. it could bappen that both have different supertypes. If t tiis
is the case. the ObjectlnputStream must match the amilable data cvit h t h *
classes that M being restored. Data for classes that are in the strcam but
that do not occur in the object being deserialized are discarded. C'lassc?i
that occur in the object but are not preaent in the streani have their fitMs
ini t ialized to default values by the defaul t serialization mechanism.
Externalizable objects: first the neargument constructor is invoked and thvri
the ieadu<ternal() method is cdled to restore the object's contents.
10. If enabled by a previous call to enabkRcsolveObject(), the resolveObject() met hocl
is calied. This allows the subclasses t o replace the object being returned if i t is
necessary to do so. The result of this method is returned as the return value of
read0 bject().
Again, the compiexity in the deserialization routine cari be blamed on i t s geri-
erality. Users could improve the performance by writing their own deserializatioii
code.
4.4 Limitations
Even thougb the reasons for forcing the programmer to declare which classes shoiild
be serializable are d i d . they introduce a problem. Specifically, for classes that will h t *
serialized (e.g. those cvhose objects will be remote objects) special attention niiist h*
paid to their inheritance chain. If a class in the inheritance chain does not implemcnt
Serializable, its su btype should take responsibility for the serializat ion of its public
and protected fields. As discussed in the previous sections, this is only possible if
the supertype implements a constmctor with no arguments. Moreover. if classes
are created extending other classes from a third party library that was developecl
without thinking about serialization, problems may arise. This consti t u tes a serioiis
problem for the development of parallelizing tooh since it cannot be assumed that
such libraries will not be utilized in the user's code.
Since our parallelizing tool will build distributed applications from the user's s c
quential code, it makes sense to make every class Serializable by default . In t his way.
objects can be moved arnong the different nodes using the default serialization mecti-
anisms. Furt hermore. performance cm be finctuned by overloading the writeObject0
method where needed (e.g. to send only a part of an array).
A way of accomplishiag this change of defaults is to modify the serialization roii-
tines in the distribution source files. In particular, the files 0bjectOutputStream.java
and 0bjectStreamClass.java could be edited to eliminate the checking that is perfornitd
to ensure t hat the class being seridized implements Serializabk. T hese modi firat ions
are simple to make and are very locdized but. unfortunately, things can still go wrorig.
In particular. if we are extending a c l a s that implements Serializable and provicies ari
empty writeObject0 method, the object will not be properly serialized. A simple wa?
of avoiding this is to modify the source code to only cal1 writeObject0 for the classt?i
that we want (i.e. those that we want to fine-tuae for performance) and not for thi*
others.
hnother probIem that needs to be addressed is the serialization of transient and
static fields. While transient fields could be left out of the serialization format (after
al1 that is the purpose of the transient keyword), static fields are regularly used ici
sequentiai applications and extra support should be added. Since there is only ontD
copy of a static field that is shared by al1 the instances of a class (which can bta
potentially distributed among several nodes), some runtime support will be needed to
manage it. A possible solution is to have one remoteobject responsible for managing
the static fields of a class, and to place a reference to this object in the stream instracl
of the field's value. This issue is further discussed in Chapter 9.
The p s t two sections described in detail the serialization process. Frorn there it
can be suspecteci that the performance of RMI will suffer because of the complexity
of the serialization process (see Chapter 5). In particular, lwking at the algori t hm
for serialization described in Section 4.2, it can be seen that each one of the ten
points corresponds to an "if" statement that handles a particular case. Many of these
cases cannot be avoided, but some of them could be eliminated at the expense of
lasing some functionaiity. For example, if object replacement is discarded, step S
and part of step 3 can be eliminated. OR the same track, if versioning of classes is
not supported (which is not needed for parallel systems), then the computing of thc
serialversion UlD could be avoided together with the code that handles the evoliit ion
of types when deserialking an object. Other optimizations are possible. includitig
custom seridizat ion routines, and the use of shallow copies where possible to redti~x.
the amount of data that needs to be exchangeci.
As shown in this chapter, the problem of tagging classes as Serializable is ptirrlu
a Java issue. On the other hand, the issue of how to manage static fields will arisc i i i
any object-orienteci laquage that supports class variables such as Smalltalk [(;KS:l]
and C++ [StrSl]. However, in Smailtalk this problem is easier to solve because ati
object can only access the fielda of another object by using methods. Furtherrnort*.
this issue is also present in procedurd languages like C when deding with global data
structures.
Chapter 5
Performance Evaluat ion
To decide how to distribute a paralle1 application among the avdable processii~g
nodes, i t is imperative to consider several factors such as processor avaiiabili ty aiid
workload, security policies in place, and. in particular, the costs involved in tranr-
forming a local object to a remote one. II is important to get an exact appraisal of
these costs to make intelligent decisions about the paxtitioning of the application mil
the distribution of its objects. Clearly, if creating a rernote object takes longer tliari
the time that the object is expected to r u , it is wiser to create it locally. A1.w. aftw
an object is remotely created. dl the remote methods invoked on that object will
incur extra communication overhead. This means that if some methods of a partiru-
lar object are cdled frequently. then this object is likely not a good candidate to bt*
made remote. Moreover, two objects which frequently tdk to each other are likely tu
be good candidates for clustering.
Several tests were designed to obtain some nference values for the main c o m p
nents of the RMI system's overhead. The cost of invokiog a method on a rcmotte
object can be d e c o m p d as:
RMI pure overhead: The time that the RMI system uses to do adrninist rativib
tasks (e.g. setting up connections, opening sockets, etc.).
Serialkation time: The time that the RMI system uses to pack and unpack ttic
objects sent in a cal1 (Le. parameten and retum values).
Network delay: The time that it takes to transfer the data betiveeii two nodes ( i . ~ .
parameten. control informat ion, etc.) without including the RM I pure o~~rlittiicl
1 public class Test RMllmpl utends UnicastRemoteObject implemen ts Test RM l {
public TestRMllmpl() throws RemoteException { super();
1 // Simple routines for tcsting passing // parameters of various types to remote objects public void nop() throws RemoteException { 1 public void nop(int x) throws RemoteGtception { 1 ... public void nop(Tree x) thram Remotet<ception { 1
1
Figure 5.1: Remote Methods
and serialization time. This number depends on the speed of the uncierlyirig
network and on the size of the messages being sent.
In this chapter we attempt to quantify the costs of these overheads.
5.1 Experiment Design
To get an idea about the performance of the RMI system, several test were run usirig
two IBM RS/6000 355s with 64 Mb of RAM each, running AIX 4.1.4 conncet~d
through a lOMbit Ethernet network. Al1 the tests involved timing different method
invocations on a remote object. Figure 5.1 shows the code for some of the rernott8
methods used. A different empty method was provided for each type of argument
that was tested (e.g. int, double, etc.). To get more accurate results t h e tests arrtb
run on idle machines and each mesure was the average of 1000 method invocatioris
that followed the fom of the code in Figure 5.2.
To better appreciate the overhead produced by the RMI system, the same t e t s
were run using a socket implementation (see Figure 5.3). In this version. the 01)-
ject serialization routines provided by Java were used to implement the remottb dl.
Each method was assigned a number. and the cal1 was made by cvriting that niirnhr*r
long tb, ta; long et; int it = 1000; // Call a remote method 1000 times and time it tb = System.currentTimeMiIlis(); for (int i = 1; i 5 it; i++) {
RemoteObject SomeMet hod(Parameters);
} ta = System.currentTimeMillk(); et = ta - tb;
1 System.out.printIn(" Avg. round trip for SomeMethod(Pararneter s): " +etlit+" ms" );
Figure 5.2: Elapsed Time Algori t hm
Socket 5;
ObjectOutputStrearn sout; ObjectlnputStream sin; long tb, ta, et; long it = 1000;
// Create socket and output Stream s = new Socket(lnetAddrw.getLocalHost(), 6010); s.xtTcpNoDelay(true); sout = new ObjutOutputStream(r.getOutputStream()); sin = new ObjectlnputStream(s.gethputStrcam());
// Time 1000 socket calls tb = Systern.currentTimeMiIlis(); for (int i = 1; i 5 it; i++) {
~>ut.writelnt(OPERATION-CODE); // first wiite the operation code sout.writeObjcct(PARAMETER) // then write the parameters sout .flush(); sin .readln t(); / / wait until the method has been excecuted
1 ta = System .currentTimeMiIlis(); e t = ta - tb;
S ystem .ou t . printIn(" Avg. round trip for SorneMethod(Parameters):" +et/it + (" ms" ) ;
Figure 5.3: Sockets Implementation
1 1 one node
Double 25
paramet er no parameter
L
Double0 Tree
Table 5.1 : Experimentai Results
sockets (ms) 5
- -
two nodes
to an ObjectOutputStream (that was pnviously bouad to a socket) followed by t h
appropriate parameter. Then the result value of the method was read lrom an Ob-
jectlnputStream bound to the socket (since al1 the methods had a void return ~ I i i t b .
an int was uscd as an acknowledgment).
RMI (ms) 14
sockets (ms) 5 6 7 7 7
3 t
8
5.2 Experimental Results
RMI (ms) LI 16 17 28 29
281 387
The results of the experiments are summarized in Table 5.1. The minimum cost
of an RMI cal1 occurs wben an empty method is executed on a single nodc. The
experiments show that the minimum performance overhead incurred by the R M I
system fdls in the neighborhood of 14ms. This overhead clearly irnplies that any
computation that is expected to run for less than 14ms is not a gmd candidate tu
be performed remotely using RMI (although it can still be moved for other reasoris
such as fauk toierance). Using an empty RMI cal1 permitted us to isolate the purtb
overhead from the seriaiization time, as there were no parameters or return valuce
to serialize. Likewise, the pure overhead was isolated from the network del- by
running the test on one machine done (i.e. two Java virtuai machines in one physical
machine).
The implementation that used just sockets and object serialization, on the otht~r
band, took only 5ms to perform the neargument call. This suggests a significant inrf-
ficiency in the RMI system. Unfortunately, the design of the reference and transport
layers of the RMI system is not documented (only the interfaces are documented).
Furthermore, the source files of the classes that irnplement these iayers are not pro-
vided with the Java distribution. Thus, it is almost impossible to fully explain wherc
the time is spent inside the RMI layers. However, we used a decompiler to take a
look at the main classes that comprise these layers to get a better understanding of
the RMI system. The exploration of these classes reveded a fairly cornplex desigri.
Moreover, this design cannot be compared to the sockets irnplementation that wtB
made. Besides creating sockets, the RMI irnplementation creates several t hreads ancl
performs several other tasks, such as protocol negotiations and garbage collectioii.
For example, one of the threads created is a Pinger thread whose function consists of
sending periodic messages to the other side of a communication channel to test t lit.
liveness of the connection. Another interesting thing we noticed is the preseiicr of
debugging code. In particular al1 the code is populated with "if" statements t hnt trst
for different properties and output the appropriate information to log-files. C'learly.
these "if" statements contribute to the poor performance of the RMI system.
Since the socket irnplementation and the RMI implementation both used the sartitl
pack and unpack code (i.e. the object serialization feature of Java), the differt.rict8 i i i
our test program tirncs can be attributed solely to the RMI overhead. A s disciisstvl.
this overhead is attributed to debugging code, thread management, thread contc8xt
switch, etc. However. the user of RMI benefits from the RMI's ease of use. Invokiiig
a remote method using RMI is much easier than programming the equivalent socktbt
version.
To test the performance of the serialization routines of RMI, empty remote met h-
uâs. as shown in Figure 5.1, w r r r d. DiKerent ruas were made changiiig t l i ~
parameter type to see how this affectcd the performance. Two primitive data types
of different size were tried: int (32 bits) and double (64 bits). As shown in the table.
the time that it takes to serialize and send a primitive data type a c r m the netrvork
is insignificant compared with the RMI pure overhead.
Other types were also used a9 parameters. In particular. objects of type lnteger
and Double were used to compare the times with the ones obtained for the eqiiivalcrit
primitive data types. The nurnbers in Table 5.1 show that it is much more exptwiw
to send an lnteger (Double) object than to transmit the corresponding int (double)
primitive data type. This is because the seridization of objects is more complex thari
the seridization of primitive data types. For objects, class information is placed in
the stream and extra dispatches are performed to pack the object's contents (sec
Section 4.2). However, the socket version seems less affecteci by this t han t h e Rh1 1
version.
More complex structures were used to see how the RMI performance was affcctrd.
Four different m a y s of 100 elements were tried: an array of int numbers, an art-
of double numbers, an array of lnteger objects. and an array of Double objects. :\lso.
a binary tree made of 100 objects, each containing an integer number, was u s ~ d
as a parameter. These experiments confirmeci the fact that dealing with objects is
more expensive than dealing with primitive data types. Also, serializing t h e t r w
took longer than serializing an equivalent array. This is explained by the fact that
each node of the tree contained two object references besides t h e int value. For (-art1
of these references a handle was written. On the other hand, when serializing tlit*
array, its size is written once followed by al1 the elements (see Section 4.2). While t t i ~
performance of the socket implementation remaineci almost constant for the di Kererit
types. the performance of RM 1 deteriorated.
The tests were also run on two nodes with similar results. This irnplics that
the network delay is not a significant factor in the total overhead. In other worcls.
for the types used as parameters, no performance improvement can be achieved b!.
using a faster network. The numbers for two nodes dso show how t h e Rh41 systet~i
benefited from overlapping computation and communication. When sending a n ana!.
of integen for example. while one node is serializing to the strpam, the o t her node is
deseridizing from it. This exptains the fac t &Lat Jorrie met hod invocations were fast tmr
through the network thaa Iocaily.
5.3 Conclusions
This chapter presented a performance evaluation of the RMl system. The experimrnts
revealed an important performance overhead in the RMI system. This overhead
cannot be attributed to the seridization routines but is directly caused by the R N 1
reference and tmnsport layers interna1 workings. Debugging code present in t how
Chapter 6
Inheritance
Inhefitance is a very important feature of object-oriented languages that enables tlit-
sharing of code between different class implementations. When used properly i t is a
powerful tool for software development . Java supports tree single inheritance wwhere eadi class has exactly one parent and
al1 classes have a common ancestor (i.e. the cl- Objet). From the sirnplicity point
of view. single inheritance provides an unambiguous mode1 t hat is easy to deal wi t l i
(as seen in languages such as Smalltalk [GR83]). However. sometimes this rnoilt4
lacks expressiveness w hen compared to those languages t hat support multiple inlwr-
itance (e.g. C++ [SM 11). The Java approacb for dealing with this issue is t hroiigli
interfaces, which regain some of the b t expressiveness without sacrificing the siril-
plicity. However. using interfaces sometimes forces the programmer to unnecessarily
duplicate code.
6.1 Inheritance and RMI
The simplest way of implementing a remote object with RMI is by extending t l ir
ciass U nicast RernoteObject. However, since Java provides only single inheri tance t his
is not dways possible. Moreover, if we plan to automatically translate local classt3
into remote ones, we c a n o t rely on this feature because the user classes often extcnd
some other classes. For example, suppose that the user has a ciass AccessPermits tha t
is implemented as an extension to the class java.util.BitSet which provides a growahlth
vector of bits. If we have to make objects of type AccessPermits rernote. we catiiiot
extend U nicast RernoteObject because the only available inheri tance par h is alrrad>.
consumed by java .ut il. BitSet.
Another option available is to use the static method exportObject() provided by
class UnicastRemoteObject to make the remote object available for receiving incoming
calls. In our previous example we would create an instance AccessPermits and theii
we would export this object using a Unicast RemoteObject.o<portObject() cal1 as in the
followiag code fragment:
AccessPennits parnits = new AccessPernits();
. . UnicastRemoteObj ect . erportobj ect (pernits) ;
Using this approach, however, requires some extra coding to implement the scbmari-
tics of Object that are different for remote objets. that is, the hashCode(). equals().
and toString() methods. In the k t approach these methods were inherited from Re-
rnoteobject but since inheritance cannot be used for the second approach they Iiaw
to be re-implemented. ' Even though the code for these methods can be copied Irori~
the RemoteObject.java source file that coma in the Java distribution, the code will IW
repeated for each user class that is made remote. This. besides being inconwriitwt.
is clearly less eificient in terms of space.
6.2 Inherited Methods
In the RMI systern, only the methods declared in the rernote interface of an object cnn
be remotely called. Thus, inherited methods cannot be calleci directly from a rrmottb
site. Coi idsr the iiihrritance graph shown in Figure 6.1. A Sensor class provides thr
cornmon functionality (e.g. Activate() and Deactivate()) to different types of st8nsors
(e.g. TernpSensor, NoiseSensor, etc.).
Now, let's say that we make instances of TempSensor remote. According to tht-
RMI specification, al1 the methods that will be cdled remotely should be put in the
remote interface of the class. So if the TempSensor class had, for example. a method
for reading the temperat ure (i.e. readTemp()). the remote interface should look l i kt.
the code in Figure 6.2.
'In fact they only have to he implemented if they are used-
Figure 6.1 : Sensor Inheritance Hierarchy
public interface TempSensor RI extends Remote { Temp readTemp() t h r w Remotet<ception;
1
Figure 6.2: Temperature Sensor Remote Interface
Figure 6.3 shows a code fragment that uses a local TempSensor. Basically the cock
instantiates a TempSensor, activates the sensor, reads the temperature and finail!
deactivates the sensor.
When the TempSensor is made a remote object, the code show in Figure 6.3
changes to something similar to the code fragment shown in Figure 6.4. Note that
in the remote object version "ts* is a TempSensorRl rat her t han a TempSensor. Sincc
TernpSenswRl does not contain the rnethob Actiintef} and Deactivate(), an errur wil l
be generated when we try to compile this code. For this program to work Activate()
... TempSensor ts = new TempSensor(); ts. Activate( ) ; System .out.println(" Temperature: " + ts.readTemp()); ts. Deactivate();
Figure 6.3: Local Use of TempSensor
- . . . - -
Registry registry = LocateRegistry.getRegistry(); TempSensorRl ts = new (TempSensorRI) registry.lookup(" TEM PSENSOR ); &.Activate(); System.out.println(" Temperature: " + ts.readTemp()); ts. Deactivate();
Figure 6.4: Use of TernpSensor as a Remote Object
and Deactivate() should be added to the remote interface of the temperature sensor
(i.e. to the TernpSensorRI interface showa in Figure 6.2).
This simple example demonstratni that when converting a regular object into a
distributed one, al1 the inherited methods should also be put in the remote interfacc
Automatically doing this, however, would require compiler support to find all t h c h
rnethods that must be added to the remote interface. The inheritance hierarch~
should be traversed from the class we are working on up to the Object class and thth
inherited methods should be added as we go along. However, since Java's method
dispatching is done according to the runtirne type of the receiver, the compiler will
not always be able to determine if a particular inherited method will be used or riot.
This means that the interface will likeiy include methods that will never be calltd.
To illustrate this suppose we have a class B that extends another class A. and
A implements a method alpha(). Suppose alw that the compiler is parsirig t lit.
following code:
0 b - new B O ; A a - b; // this is v a l i d because A is a supertype of B
The variable 'an hacl a compile type of A but its runtime type is B. The compiler
usually cannot determine this because instead of a simple assignment, "a' can be t ht*
result ol a more complex operation. By just looking a t the code the compiler will
oot be able to tell if alpha() will be called or not for object "b'. But. if -b' has LU
be made remote, alpha() should be added to the remote interface just in case it g ~ t s
called as i7 t h e sample code.
protected long serial-no; I *..
Figure 6.5: Sensor Class
... NoiseSensor ns = new NoiseSensor(); if (nsserial-no == 12345)
dosomet hing-specia t ( ) ; C ~ K
Figure 6.6: hccess to a Protected httribute
6.3 Inherited Data
Inheritance should also be considered from the point of view of the inherited data.
Suppose that we have the inheritance hierarchy shown in Figure 6.1 and that tht*
Sensor class has an attribute to keep the serial number of a particulas sasor (SC-*
Figure 6.5). The attribute serial-no is declared protected so it can be accessecl frorii
the Sensor class, from dl its subclassci (Le. TempSensor, NoiseSensor, etc.) arid
from al1 the classes that belong to the same package. So we could potentially
have a class in the same package which hm some code like the sample in Figure 6.6.
When NoiseSensor is made remote however, the attribute cannot be directly accessd
anymore. Code like that in Figure 6.7 will produce a compiler error becausr t h *
attribute caiinot te part of the remote interface.
Since the code in Figure 6.7 uses the remote interface as a type and since variablm
cannot be declared in an interface (ody constants and methods), the inherited valt ic .
is not known by ns. This happens because RMI forces you to instantiate the interfacc
rather than the remote cl= so only those things defined in the remote interface
(NoucSensorRI in out exarnple) are visible from the clients. A simple workarotind of
'This differs from C++ whete protcctcd fields are only sccorsible from the class where t hey appciw and h m th& subclasscs. To gct the ssme functiondity in Java the pnvate profected modifier shoiild be used iasted.
- - -
I - * - NoiseSensorRl ns = (NoiseSensorRl) registry.lookup(" NOISESENSOR); if (ns.serialno == 12345) // <- COMPILER ERROR!!!
I do-somet hing~pecial0;
e k m..
Figure 6.7: Remote Access to a Protected Attribute
this problem involves changing al1 the data accesses to remote method invocations. To
perform these changes automatically, compiler technology will be required to detect
al1 the data accesses and turn them into the appropriate set() and get() method calls.
Specifically, every place in the code where a field is used on t be left-hand side of ari
a~signment should be replaced by a cal1 to a set() method; any other use of t lit. f i t 4 c l
should be replaced with a get() method. Even though this problem is shown in thc
context of inheritance. it is not the inheritance pcr se that causes it. This probleni is
caused by the lack of encapsulation in the language. If ail the data were privattb to
the objects. and accessfd only through methods, it would be enough to convert thostb
metbods to remote.
6.4 Conclusions
As shown in the previous sections. inheritance raisa many issues when combintd
with remote objects. The first issue is how to utilize RMI in an application that iist?i
in heri tance. As shown, the single inheritance mode1 supportmi by Java is incorivrnic.ut
because it forces the programmer to choose bet ween unnecessarily du plicat i ng CO&
or to derive Lia/tcr classes lrom the RMI base ciass. Moreover, when the translatioii
from local to remote objects is automatically made, the compiler is presented rvi t li
the sarne decision. Both, the programmer and the compiler, should extend the Rh1 I
base class whenever possible to avoid dupiicating code. This problem can be direct ly
mapped to any language that is restricted to single inheritance. In those languagr*i
the programmer is always faced with the decision of which inheritance path is betttbr
to use.
On the other hand, the problem of adding the inherited methods to the rrmottB
interface is specifically RMI related (HORB [Sat96] and Voyager [VOSi] do not haw
this problem). The stub generator should directly add the inherited methods to t l i t .
remote interface. However, doing so could considerably increase the size and corii-
plexity of the stubs and skeletons generated. The solution adopted by the developers
of RMI is that the programmer should not be penalized (in terms of apace ancl/or
speed) for something that he/she does not use (i.e. inherited methods that will never
be cdled remotely). Unfortunately, wheo the translation from local to reniote i s
automated, this optimization becomes a source of confiict.
Finally, the problem that aises with the inherited data is a language issue. If
the semantics of the language were such that the encapsulation of data could not ht-
violated with direct access to the object's fields, the problem would vanish. In ttiat
case. al1 the data accesso would be made through rnethods that would be transfornitd
into remote methods when passing from iocai to remote objects. The perforinnnct*
hit suffered when doing a local method cal1 instead of a direct memory acceJs coiilcl
be lessened by using compiler optimization techniques such as code inlirting. Sottb.
however. that since Java supports dynamic method dispatching, more complcx rodv
inlining techniques such as polymorphic inline caching [HCUgl] will be reyuirrcl.
Chapter 7
Futures
Usually, in a concurrent system, achieving maximum performance involves execu t i rig
as many concurrent tasks as pauible. To increase concurrency, it is often desirahle
to synchronize only when it is absolutely necessary; that is, the blocking required to
synchronize a task should be delayed as much as possible. Consider the followir~g
code:
... System.out.priatln(% - " + x + " y = " + y) ;
Suppose that the value of the variable x is not needed to compute the value of variablt*
y. If the sequential semantics are respected, y_ExpensiveComputation() cannot start
until rG<pensiveCompu tation() has finished. However, it would be highly beneficial if
both values could be caiculated in paallel. The only restriction would be that 60th
computations should finish befom the values are printed.
To mn both methods concurrently, two threads have to be created and a syri-
chronization point has to be set up to wait for both cornputations to finish beforr
executing t be print statement. Ali this caa be elegantly expressed using a const rtirt
called a future [BEI771 [Hal85]. A future is a cornmitment GO use a particular \abc
at some later tirne. Whenever a future is created. a new thread is spacvned tu ri i i i
that part of the computation and, eventually, fi11 in the value for the future. :\t i~
later tirne, when the original thread tries to access this future, it will block unt i l the
future is resolved (i.e. the d u e becomes available). Thus, in our exampie. it wvoulcl
be enough to declare x and y as Jiturcs to obtain a correct concurrent execution. The
following code shows our example using futures:
Future r. y;
. * O
x - CreateFuture (remote,node() , xJxpensiveComput at ion 0 ) ;
// continue without blocking
y - Croatefuture (remot e-nod.O . y-ExpeaaiveComput at ion () ) ;
// continue vithout blocking
. . . UaitForFuture(x); // ve blodc only vhen it is needed
Uait ForFuture (y) ;
System.out.println("x - " + x + y - " + y);
Futures are a popuiar aynchronization mechanism used in variety of parallcl pr*
gamrning systems such as Enterprise [SS+931 and Mentat (Gri931. They werc. first
introduced by Baker and Hewitt [BH77] and later on became popular in hliiltilisp
(Hai851.
7.1 Futures in Java
The RMI system does not provide an asynchronous method cdling facility (i.e. al1 rr-
mote method invocations are qnchronous). We evalusted t h m differcnt approachcs
to implement futures in Java so more parallelisrn could be obtnined by using asyu-
chronous calls. We started from the most intuitive solution and improved from t herc.
As we saw, creating a future implies spawning a new thread for executing t h
computation. This thread c m be created on the caler or on the c a k e side. and
t here are many implications t hat affect this decision. Three approaches invest igatwl
in this thesis explore these issues. In dl of them a Future object is created. This
Future object is a remote object which provides a value holder for the future and
provides rnethods CO access it (Figure 7.1 ). Each Future object also contains a flag
package Futures; import java.rmi.*;
public interface FutureRl extends Remote { void setValue(0bject O) t h r o m RemoteException; Object getValue() throws RernoteGcception;
1
Figure 7.1: Future's Remote Intedace
that is used to record the state in which the future is at any particular moment (e.g.
unresolved, resolved, error). Being a remote object, the Future object c m be paçscd
around among different virtual machines and its d u e can be retrieved from rvhere it
is needed. This constitutes a step forward from some designs where the futures arcD
not able to move (e.g. Enterprise [SS+93]).
7.1.1 Server Side Futures
In the fint approach, cailed Semer Side Futures, the Future object and the extra
thread are created on the server side (see Figure 7.2). Whenever a client exrbcutt?i
a remote method (e.g. cornpute()) on the server. the server spawns a nerv threacl
to execute the methocl and irnmediately returns a Future object to the client. ' A t
this point the client can continue executing concurrently with the computation that is
mnning on the server aide wi thout blocking. The server is responsi ble for updat ing t lit*
vaiue in the Future object w henever it becomes ready by using the met hod setvalue().
which is part of the Future's remote interface (see Figure 7.1). The met hod setvalue().
besiden storing the mlucof t he future, wake up dl the threads, if =y, tthat arc blockcd
waiting for the future. If the client tries to access the vaiue in the future. using t l i ~
getValue() met hod, before the future has been resolved ( i.e. before the server u pdates
it), the client will block until the vdue becomes available. This blocking is doric*
by using the thread synchronization primitives of Java. Inside getValue(), wait() is
used, if necessary, to suspend the executing threaâ. This, in turn. will stop th
method getValue() from returning until the thread is awakened by a notifyAll() cal1
'Note that since the future is a ternote objcct, it is pairscd by refcrence and. thw. only a han* is returned ta the client.
Figure 1.2: Server Side Futures
in setValut(). If for some reason the computation is aborted on the server si&. t h
client trying to get the d u e from the future will get an exception instead. See Figtrrv
7.3 for sample code.
7.1.2 Client Side Eùtures
The second approach, c d 1 4 Client Side Futures (see Figure 7.4). is an optimizatiorl
over the Semer Side Futures approach. Even though both are semantically equivaletit . the Client Side Futums approach redrrces the inter-virtual machine messages necessary
to create the Future object and start the computation. In this implementation. tlitb
future is created on the client side and then passed to the server as an extra pararncttbr
of the remote met hod invocation. Note that even though the Future object is created
on the client side, the thread needed for executing the computation is still creatrd
on the server side. Since the future itself is a remote object, the extra overhcad of
sending anot her parameter is minimal because remote objects are passed by refereric-t-
(Le. only a handle is sent). The semantics for accesing the Future object rerriairi t lit*
same. On the server side the code is sirnilar to that of the previous approach with
tv ( Regist ry registry = Loca teRegist ry.get Regist ty(); serverRI =mer = (serverRI) registry.loookup(" SERVER );
FutureRl f = server.compute(); // Client continues executing ...
// Client will block when accessing the value. lntcger i = (Integer) f.getValue();
) catch(Throwab1e t) { // Error handling code ...
//-[ Server Code ]- private int func; rivat te Remott f;
// A dfierent ID for each method.
mblic synchronized FutureRl cornpute() throws Remotetrception { func = 1; // set method ID for execution. f = (FutureRI) new Future(); new Thread(this).start(); return(f);
1
~ublic void runo { Thread.currentThread(). yield(); switch(func) { // identify which method should be utecuted.
case 1: { // rtatic dirpatch. 1 int i = real-cornpute(); // the original code for cornpute() 1 try {
f.setValue(new f nteger(i)); )catch(Throwable e) {
i // Error handling code ...
1 1 case 2:
// a case for each method remote method that has to be // executeâ in r separate thread.
Figure 7.3: Code for Server Side Futures
the exception that instead of instantiating a Future it uses the instance provided by
the client. On the client side the code looks like:
. . . FutureRI f = new Future() ;
srv.compute(f) ; // srv is a refesence t o the server object
... // which residea on a different virtual machine.
Both approaches rqui re changes to the server side code to spawn a new threacl
for executing the remote method. This is necessary because the method is required to
return immediately wit hout blocking. Furthermore, since Java t hreads only excïutt8
the code placed in the run() method, it is necessary to niake a static dispatch insiilt-
the server for each remote method we plan to execute in a separate thrcad (stv t tw
switch in the run() method of Figure 7.3). This makes the required changes to tliv
user code more ditncult. Also. the signature of the remote method should be charigd
t o return a Future in the first approach and to include an extra parameter in t l i t .
second (besides changing the return value to void).
Client Side Futures / hiture Computes
The third approach, called Client Sidc Futures / Wiurc Computes (see Figurr 7.5).
is an attempt to alleviate al1 the problems stated in the previous section (i.e. to
minimize the required changes to the user's code and t o eliminate the static dispatch
inside fun()). In this case. the future is created on the client side and it is responsibltb
for executing the rrrtiok method. Now, the server code rernains unchanged ard
the future is a threaded object that will block on behalf of the client. Note. t h
this time the thread used for running the cornputation is created on the client si&..
Another way of achieving this would have beea by making the client a threadtul
object. However, Java imposes the restriction that run() is the only method that a
thread can execute, forcing us to modify the client code in the same way as we dit1
with the semer code in the previous two approaçhes. That is, a static dispatch should
be coded inside the client's runo method. Creating the thread on the future itsrlf
eliminates al1 these problcnis. When the future is created it receives a r e f e r r r w tu
Java VM
Figure 7.4: Client Side Futures
the server and a method signature to execute on t hat server. The future will use t t i c *
Reflection API to make the cal1 (see Figure 7.6). The Rcflection .4PI provicln tht*
functionality neccssary to gat her informat ion about fields, met hods and const ruct ors
of loaded classes, and to operate on them. In particular, in the code showri, i t is i i s w i
to execute a specific method on the server with the specified parameters.
This approach has the advantage of keeping the server code untouched. Horvever.
executing a method through the Refiection API is mon expensive because it involws
a table lwkup for findiag a method in the server's class that matches the specifirtl
signature, an object instantiation to create a Method object that 'reflects" the spw-
ified method, and a dispatch to execute this method on the desired object (SC* th<%
run() method in Figure 7.6).
A possible workaround of this performance problem consists of subclassing tht*
Future class. The Future class should be changed to be an abstract class wit h ail
empty method, called ex=(), that will be called ioside runo. Each tirne a future i3
needed to asynchronously execute a method, an appropriate subclass of Future shoiild
be used. This subclass should provide the implementation of exec() which will execittts
Java VM l l a Jawa VM O l
armata ( O m V a t * *caqtit.",; prototypa* p u m 8 ) : '
CLIENT ..
# *
Figure 7.5: Client Side Futures / Future Cornputes
the desired method. The rest of the functionality will be inherited from the Future
class. Even though this subclassing can be inconveaient for a programmer, it cari IW
easil y performed by the parallelizing compiler.
7.2 Limitations
Regardless of the approach chosen for implementing futures in Java. some coriiniori
problems also need to be addresseci. The first problem is how to stop a computatiori
once it is running. Suppacie that an application searches a binary tree looking for
a specific value. One possible implementation might have two futures created: oiitb
for a computation that performs the search on the right branch, and the othcr for
searching the left branch (speculative computing). Clearly, if one of the computat ions
retums having found the value (i.e. the future is resolved), then the other future can
be discardeci. A simple way of dealing with this consists of doing nothing; that is.
taking the first result and ignoring the second. Even though this solution is simplv
to implement, it has the undesirable effeet of wasting CPU cycles to compute a n l i i t b
that will never be used. An alternative to this involves providing a nietbod tu s t q ~
1 public class Future extends UnicastRemoteObject implements FutureRI, ~unnable (1 // attribute declarations ... public Future(Remote srv, String name. Class -prototypeo. Object -parmsu)
throws RemoteException { super(); // Since run() doesn't have parameters the data is kept on attributes. value = null; state = Future.NOT4EADY; ScIver = sw; method = name; prototype = ,prototype; parms = ,parms; new Thread(this).start(); // Creates and starts a new thread. return;
1 public Object getValue() throws RemoteException {
while (state == Future.NOTREADY) ( tv t
wu&(); // block the client thread. ) catch (InterruptedException e) { }
1 return(value);
1 public void run() {
Thread.currentThread().yield(); Object O = null; Method rn;
trY { // Cet a method object that matches the prototype // on the cliw of the server. m = rnrer.getClass().getMethod(method. prototype); // lnvoke the method on the setver with the saveâ parameters. O = rn.invoke(sewer. parms);
)catch (Throwable t) { System.out .println(t .get Message()); t.printStackTrace();
1 value = O; // Set the value of the future. state = Future-READY; // Mark the future as ready. notifyAll(); // Wake up al1 waiting threads.
} 1
Figure 7.6: Future's Code for Client Side Futures / Future Compiitt?i
z-1
the desired computation. This method should be implemented in the server or ici
the future according to which approach has been taken for implementing the futures.
If the thread that is executing the computation has been created by the server ( i . e
Semer Side Futures or Client Side Futures), the method for stopping it should br
added to the semer's class. If the thread has b e n created by the Future object (i.e.
Client Side f;ktums / Futum Cornputu), the Future class should provide this methocl.
Regardless of its location, the implementation of this method should stop the t hread
that is running the computatioa by sending it the message stop().
Another problern that requires attention involves exceptions. Exceptions are a
cornmon feature in many modem languages such as C++ [Str91]. Suppose wc haw
the following sequential code:
t r y Integer i - server. coipute() ;
Use (i) ;
> catch(SomeExcoption e) {
Do something with e. . . >
If t h e corn pute() function throws an exception, control ski ps to the catch claiiw.
and the function Use(i) never gets called. Now if 'i" is made a Future and passed to
Use(i), when the exception is thrown on the semer, it is too late to recover. That
is, by the time that the exception is thrown, Ux(i) could have made some changta
andior pedormed certain actions that could not be reversed. A partial solution to t hi5
problern consists of using two futures to represent the d u e calculated by cornpute().
The first future corresponds to the d u e 3"; the second represents the return code for
the function. The idea is to block in the future representing the return code insteacl
of the future repraienting the value. The future representing the return code will b t b
resolved as soon as the server passes the place where i t can t hrow the exceptioii. Th<%
code in the client will look like this:
lThe message stop() U understood by every Java thread and forces it <O stop executing.
=*a
FutureRI rc;
FutureRI i = server.conpute(rc);
// Block until the server signals that no exceptions can happen.
Exception e = (Exception) rc.getValue();
if (e) // if an exception occurred. . . Do something v i t& e . . .
else
Use(i) ;
This technique of dividing the server code in two parts, one that can throw excep
tions and another that cannot, allows oome concurrency while retaining the corrrct
sequential semantics for the code. However, extensive compiler support will be needrd
for automating this task. The compiler should identify the point in the server codtb
were no more exceptions can be thrown and resoive the future that holds the retiirrl
code.
An alternative solution consists of using transactions similar to those which artb
common in modern databases. The state of the objects should be saved before tbvcbr!
change and rolied back as neeùed (i.e. when an exception is thrown). Althoiigli
semanticaily correct. this solution wouid be hard to implement and the perfortnanct*
wouid probably be unacceptable.
The simple example presented in this section demonstrates that exceptions cari
seriously d u c e the opportunities for coacurrency. Since the use of exceptions is
strongly encouraged in Java. creating concunency while preserving the original sib-
quentiai semantics becomes very difficult. This posses a serious problern for t h
development of an automatic parallelization tool. Moreover, since exceptions are a
common feature in many modern languages this problem is not limited to Java aloric
7.3 Discussion
As shown in the preceding text, it is generally better to create the Future objtbct oii
t he client side. This reduces the inter-Virtuai-Machine messages at creatior~ t i i i i t *
resulting in a more efficient design from the performance point of view. Howwvt*r.
creating the Future objeft on the server ride may still be desired for load balancirig
reasons (e.g. the client machine may have too many objects, or rnay be running out
of memory, etc.).
The complexity needed on the server side t o asyachronously execute different
actions can be avoided using the Client Sidc Futures/ Future Cornputes approach.
The Future object is responsible for executing the remote method and the Reflectioii
API is used as a generic dispatching mechanism. Alternatively, the performancr
overhead of the Reflection API can be avoided by subclassing the Future class.
Special attention bas to be paid to exceptions in the presence of futures. A s shown.
if the sequential semantics have to be presenred in the face of exceptions, then t hr
concurrency provided by asynchronous messages rnay become severely limited.
I t is important to point out, however, that the limitations previously descrihd
are not a flaw of either Java or the RMI systern. The problern with exceptions will
arise in any language that supports this particular construct (e.g. C++), and the.
problem of how to stop an ongoing computation is intriasic to the parallel computirig
paradigm. The most serious of these two limitations is the one involving exceptions.
If futures are to be used in languages that support exceptions. more research will
be needed to find a better way of integrating both constructs (i.e. exceptioi~s arid
futures).
Chapter 8
Collaborators
An object-oriented system can be viewed as a group of objects that commiinicatt~
among themselves using messages to achieve a particular goal. We can Say that t h c w
objects collaborate with each other to solve a particular problem towards the corii~ti~ii
objective. In this scheme. any object whose methods are invoked by another objrrt
is said to be a collubomtor of the second.
This chapter explains how the concept of collaborators relates to the automatic-
parallelization of aequential programs. First, a working example is presented which is
used to illustrate the impact of the different distribution decisions (i.e. what are ttir
consequences of selecting different objects to be made remote). Then, the probleiii of
automating these decisions is dixussed.
8.1 Example
Suppose we have an object that represents a temperature seosor which is an instanctb
of the class TernpSenriu show in Figure S. 1. .41w gsuppose we have on objcct of typc
TempDisplay (see Figure 8.2) that displays a temperature on a console screen evt-ry :IO
public class TempSensor extends Sensor { public Temp readTemp() {
Temp t = Physically-read-temperature(); return t;
1 1
Figure 8.1: Temperature Sensor
cl:
public class TempDisplay extends TextField irnplements Runnable { private TempSensor ts; public TempDisplay(TempSensor t) {
ts = t; 1 public void run() {
while (truc) { // do forever // use the temperature sensor to // read and display the current temperature. t his.setText(ts.readTcmp());
try { writ(30000): // wait 30 seconds.
} catch(lnterruptcdException e) () 1
1 1
Figure 5.2: Temperature Display
seconds. Since each time an instance of TempDkplay needs to display the temperatiirc8
it invokes a method in an object of clasa TempSensor, we can Say that the objccts of
class TempSenror are collaborators of those of class TempDisplay.
A collaboration diagram can be dawn where the objects are represented by circlw
and the rnethods by directeci arcs. Figure 0.3 shows the collaboration diagram for our
temperature sensor examplc. Each object pointed to by an arrow is a collaborator of
the object at the ot her end of that edge.
8.2 Collaborators and RMI
The purpare of this section is to show how the collaborators affect the translation
of local objects into remote ones. As long as an object and its collaborators are on
the same virtual machine everything works properly. Suppose now that we decide to
place one of the objects on a different virtual machine. In our example let's say thnt
we are interested in monitoring the temperature of a remote oven that is controllecl
by some cornputer. Hence. we have to make the instance of TempSensor a reniotc
object. In doing that we have made readTemp() a remote method putting it in t t i t b
remote interface of TempSensor. Moreover, the reference to a TempSensor that is ht+i
Figure 8.3: Collaboration Diagram
by the instance of TempDûplay will now be of type TempSensorRl (i.e. the rcrnottb
interface). Now, both objects reside on different virtual machines but. thanks to tilt*
transparency provided by RMI, the syntax of the invocations remains the sanie and
everything works as planned.
Now suppose that instead of choosing the instance of TempSensor as our rtbrtiotte
object, we opted for an instance of TempUisplay. Even though this decision s w i i i s
awkward and that the previous solution appears to be the *naturai" choice. this nvw
set ting could be the result of a compiler (or pdlelizing tool) decision. Furt hermorcl.
a parallelizing tool should be able to haadle aay placement strategy (i.e. any class
can be chosen to make it remote). If objects of TernpDisplay are remote it means t hat
they will not be able to invoke readTemp() because the instance of TempSenxrr wsidcs
on a different virtual machine. Note that the coastructor of TempDisplay receives a
reference to an object of type TempSenror as a parameter. This reference cannot hr
to an object that resides on the same virtual machine because the whole point was
to have both objects residing on different virtual machines. Thus, in order to niakr
this scheme work, we need to also make the instance of TempSensor a remote object.
This clearly implies that whenever we make a sequential object remote. we alsu
have to make al1 of its collaboraton remote objects (more precisely, those that r t l i i d i a
on a different virtual machine). Even though both solutions work. the first choiw is
better because it provides the same functionaiity with legs resources (Le. one remottB
object instead of two). Since every collaborator of a class that is made remote has to
be transformed into a remote object, a domino effect, whete most of the classes are
converted, could result. It is important to reduce this effect to a minimum becaiise
the cost of invoking a remote method is much larger than the cost of executing a
local method, and classes that reside on the same virtual machine should not bc
forced to pay an unnecessary performance penalty. In particular, a remote invocation
involves the serializat ion and transmission of the met hod's parameters and ret urii
d u e which could be a very expensive process as discusscd in Chapter 5. Yott~
t hat even if the d e r and the c a k e of a remote method both reside on the sanie
virt ual machine, this process remaiw the same (Le. parameten and retum values arc
seriaiized and transmitted through the RMI's layers). Suppose in Our examplc t h
TempDisplay has another collaborator for getting the time of the day; let's say Timer.
In the first solution, the instances of Timei will not be afkcted by making TempSensor
remote. However, if TempDisplay is chosen instead, the instances of Timer will also
be transformed into remote objects and the method for getting the time of the c h !
will be transformed into a m o n expensive remote method.
8.3 The Translation Process
As shown in the previous section. al1 the collaboraton of an object that is bciiig
converted from a local object to a cemote object should also be conver:ed. If t Iw
programmer is the one manually perfomiag the translation, he/she will be responsi hic
for identifying the collaborators aad to make appropriate decisions about what goes
whem. If this decision is given to a compiler or to an automatic parallelization tool.
the collaborators of a class should be automaticaily detected. A safe approach woiild
be to make every object a remote object. In this way, any object can be placcd
anywhere and its methoda CM be c d e d from any other node. Even though ttiis
approach works, performance suffers for each remote method invoked on an objrrt
that raides on the same virt uai machine as the caller object.
However, if the distribution of objects is static (Le. object migration is not sup
ported), sorne optimizations can be applied. Instead of making every object a r m i o t t U
Figure 8.4: Collaboraton Detection
object, only a group of selected objects together with their collaboraton are rnaclv
remote. In this way, t h e performance overhead of a remote cal1 is avoided for iinaf-
fected local objects. To implement this, the compiler should be able to determine ;dl
t h e collaborators of a given clas. For doing that, the source code alone will not btu
enough because the compiler could be fooled by the method dispatching semantics
of Java and the existence of public objects. Consider the following example: t hrtv
classes, A, 8, and C, where class 6 extends class A and both irnplement a rnethod
alpha() (see Figure 8.4). Now suppose that the code in main() is like the following:
public B b = nev 0 0 ;
public A a = b;
Consider the following code in class C:
a.alpha() ; // this invokes alpha() of class B.
When the compiler finds a.alpha() in clam C, it CM assume that A is a collaborator
of C. This happens because Java dispatches according to the runtime type of the
receiver, which in this case is different from the compile-time type. In this exarnplv.
the compiler would have made the wrong claos remote.
Clearly, the compiler done is not enough to determine the collaboraton of a class
from the source code. Extra information is needed. ' This information can be ob-
tained from hints supplied by the user, andfor from the application structure. For
' Note that insicad of an asignmcnt. *am can be the rcsult of a more corn plex operation (ii (-an cven be retrievcd from disk).
example, in a parallel application development framework based on patterns [C tl+9-1].
where the user develops the application by filiing the code sections in the providrd
patterns, the structure of the patterns allows the compiler to unarnbiguously deter-
mine the collaborator set. For example, suppose we have a pattern that represents a
pipeline with several stages. Suppoae also that, according to this pattern, each stage
finishes its task and then cals a method on the next stage to p a s the results. Froni
the structure of this pattern, it can be determined that each stage is a collaborator
of its previous stage (except the first one of course).
If extra information is not available, a compromise solution could be adoptecl
where the compiler rnakes remote the c l a s that it detected as a possible collaborator
and al1 of its chitdren. In the example above, A and its children (i.e. B) will be macle
remote. Even though this solution produces more remote objects than really neciriI.
it is better than rnaking ewrything rernote (and is just as saie).
Providing that the set of collaborators can be determined. another possiblt* op-
timization concerns t heir met ho&. Even though the collaborators have to beconita
remote objects, not al1 their methods need to be made remote. Only those methods
that are part of the collaboration relation (i.e. the arcs on the collaboration diagriun )
should be put in the remote interface. In this way, the methods that can bc call~*d
locally will not incur the performance penalty produced by the RMI system.
Even if the collaborators can be detected, the issue of which local objects shoiild
be made remote still remains. As the example in the previous section pointed out. a
careful selection of the objects that will be made remote caa produce better resiilts.
Consider for example the collaboration diagram of Figure 8.5. The arcs are labelcd
with the expected number of invocations for each particuIar message. This nurnber
can be obtained as a hint from the user or by using an instrurnented version of tlw
program (Le. a version that can record profiling information), and obtaining t i l t .
nurnbers by running the program.
Looking at the diagram and without considering the number of invocations. wts
can Say that those objects that have incoming arcs and no outgoing arcs are t l i t b
best candidates to be made remote because their collaborator set is empty. In oiir
example, moving object D to a difterent virtual machine is easy since no ot her objrct
has to be made remote. Even ttough other factors, such as computation graniilarity
Figure 8.5: Ceneric Collaborat ion Diagram
and nurnber of expected invocations, should also be considered before deciding for a
particular object, important clues CM be gathered from the collaboration diagrani.
For example. making object B remote forces objects A and D to also be reniottb. This
rnay be not desired since B will incur extra overhead for each of the LOO0 invocatiotis
of A. Before comrnitting to a particular decision though. the computation tinit! of
each method should also be considered. It couid happen that the computation tirrit*..
are such that moving B is the better option. However, if the relative tirnes of t h t *
rnetbods involved are similar, the collaboration relations can give a good hint about
t hc partitioning. * The problem of staticaily assigning tasks to processors has been extensively stiid-
ied in the past (see [LOS] , [NH85], [TT851 and [WM93]), and those experiencn cari
be applied to address the application partitioning problem (i.e. how CO distribute t lit.
objects into the amilable processors). - - - - -
'Note that if an instrumenteci version of the progrun is available, afker running it the dingrarii coutd be extcnded to include the computation tirries.
8.4 Summary
Any object whose methods are invoked by another object is said to be a collaborator
of the second. As shown in this chapter, converting a local object into a remotc*
object results in d l of its collaboatoni also being convertecl. If the cost of invoking a
remote method were similar to that of a local method, then the collaboraton probleiri
could be solved by making everything remote. Unfortunately, this is not true in Rbl l
and, thus, performance will suffer by implementing this solution. To minimize the
performance overhead, only some objects and their collaboraton should be made
remote. The problem of automatidly determining al1 the collaboraton of a class
requires extra information that cannot be obtained from just a static analysis of tlir
program (e.g. user hints).
Finally, it should be pointed out that the collaborators issue is not a problrrri
of Java or the RMI systern. The concept of collaborators is present in any objert-
oriented language. The issues discus~ed in this chapter will arise whenever a wqiiential
object-oriented program is translated into a p d e l one.
Chapter 9
Runtime System
While some of the RMI's limitations can be addresseci by using compiler transfornia-
tions (e.g. replacing direct field accesKs by remote method calls), othen, such as the
lack of dynamic object creation, require some support infrastructure. This support
infrastructure can be provided as a library of classes and a runtirne system which cari
be used as the target for our pdle l i z ing tool. The iibrary of classes will proviclc t l i t b
implementation for al1 the abstractions that will be used by the runtime systern and
by the parailelizing compiler. For example, a component of this library would hc t h
classes and interfaces that are needed to implement futures as discussed in Chapttbr
7. The ~ n t i m e system is a piece of code that is run on every participating node ( i . ~ .
each host in t he network). When fully implemented. the runtime system will provicitb
the functionality necessary to overcome most of the limitations of the RMI systcnl.
The features of the runtime system include:
0 Dynamic object creation,
0 Remote object's data caching,
Access to static methods and variables,
0 Load balaacing and,
Object migration.
In this chapter we present an architecture for a prototype runtime systenl that
provides dynamic object creation and a basic load balancing scheme. A dis<-iissioti
' import java.rmi.*;
public interface ObjectServerRI utends Remote { Remote CreateObject(String classsame) throws RemoteException;
1
Figure 9.1 : 0 bjectserver's Remote Interface
about how to extend the prototype to include the rest of the features is also presented.
Even tbough our prototype is tailored to Java/RMI, any automatic distribution sys-
tem (e-g. for C++), will require a similar runtime system (the exact list of featiirt*~
will depend on what it is provided by the underlying system). An example of thv
transformation of a simple sequential application to a parallel one is aiso included to
illustrate the use of the runtime system.
9.1 Prototype Runtime System
Dynamic object creation is a vital feature for the development of object-orientcd
parailel applications. Unfortunately, the RMI system does not support it. In RhH.
server objects have to be created and started up on different nodes before a client
can remotely cail a method on them. For translating user sequential code. howcvt-r.
we need to be able to dynamically create objects on different nodes. Thus. one of t lit.
responsibilities of the runtime system is to support this feature. For doing so. we will
use a remote object, an instance of ObjectSennr, on each node that will be responsiblt-
for dynamically instantiating remote objects on that node. Each parallel applicatioti
can have i ts own set of ObjectSemr objects (one per ride) or the ObjectServer objtx-ts
can be shared among severd parallel applications. The factors that affect this decisioii
include: fault tolerance, concurrency, and available resources. The remote i nt erfarr
for the ObjectServer is shown in Figure 9.1. A client that ha- a reference to an
ObjectSewer can use the method CreateObject() to instantiate a remote object of t lie
specified class on the node where the object server resides. For obtaining a referencr
to the pmper ObjectServer, a Schedukr object is used.
The Scheduler object is responsible for impiementing the load balancing policir?,
defined for the application. Figure 9.2 shows the architecture of the runtime systcbiri
NOOE N
Figure 9.2: The Runtime System Architecture
for an application that is running on N nodcs. Each node has its own Scheduler a i d
ObjectServer. Each tirne that an object needs to create a remote object, the local
Scheduler is contacted to obtain a reference to the ObjectSewer that resides wherr
the object will be created (( 1) in Figure 9.2). In the prototype we built. Scheduler
objects are regular objects (i.e. not remote) that implement a simple round robiri
policy among dl the participating nodes. The nsmr of a node is obtained Ironi a filr
that lists al1 the avaiiable nodes. If a more cornplex load balancing policy needs to 1~
implemented, the Scheduler objects should be made remote so that they can exchangr
ioad balancing information among them t hrough remote met hod invocations.
The ObjectServet implementation c rea ta an instance of the specified class. and
exports it before retuming the remote reference to the caller ( s e Figure 9.3). The
Init() met hod registers the ObjectSemr object with the local regist ry (the appiicat ion
name is used as the key). Note that this cannot be done inside the constructor brraitstb
the object is stiil being created when executing the constructor and. thus. an extra
package RTS; import java.rmi.*; import java.rmi.registry.*; import java.rmi.server.UnicastRemote0bject; public dass ObjectServer extends UnicastRemoteObject irnplements ObjectServerRl {
public O bjutServer() t hrows RemoteException { supei():
1 public Remote CreateObject(String clasrname) t hrom RemoteException (
Class c; Remote r; r = null;
try { c = Class.forName(classnarne); r = (Remote)c.newlnstance(); U nicast RernoteObjut .acportObject(r);
} catch(Thtombk e) {RTS.fail(" Fatal Error:" , e);) return r;
1 public void Init(String appname) {
trV t Regist ry regist ry = Loca teRegist ry.get Regis try ( ) ; registtry. rebind(appnarnc. t hk);
} catch (Exception e) {RTS.fail("OS.lnit() faiid". e);)
1 1
Figure 9.3: OhjectServer's Implementation
method is needed.
After a remote object is created by the ObjectServer, it can be accessed (i.e. its
remote methods executed) directly from any object that possesses a reference to i t
((3) in Figure 9.2). Note that a reference CO a remote object, if necessary. can bcb
freely passed amund through the network ((4) in Figure 9.2).
9.2 Example
In this section we show a complete example of how a sequential application can bcb
modified to run in parailel using our system. The sequentid code will be parallelizrd
according to the SPMD mode1 for parallelism, but other models coiild have btrri
public class HelloWorId { static public void main(String arv0) {
Hello h = new Hello("World"); System .out.println(h.Salute());
1 1
/ /O[ Hello.java Eh public clas Hello {
private String msg; public Hello(String m g ) {
msg = -msg; 1 public String Salute() {
return(" Hdlo " + msg + " !!!"); 1
1
Figure 9.4: Hello World Application: Sequentia Version
chosen instead (i.e. it is not mandatory to run the same ptogram on each node). ' Consider the sequential user code shown in Figure 9.4. The HelloWorld applicatiori
consists of two classes. HelloWorld and Hello. The c las HelloWorld implements main()
which in turn creates an instance of Hello using the constructor Hello(String -mg).
Then it uses this instance to print 'Hello World!!!" on the screen. The class Hello
provides a method, Salute(), that retums a salutation message.
The fint step in transforrning this application into a distributed one that usty
RMI and the runtime system is to write a remote interface for the class Hello. .This
remote interface can be eaoily generated by a compiler and will contain a method
declaration for each of the met hods in the original cIass. Figure 9.5 show the rtbniot t-
interface for the class Hello (i.e. HelloRI). Every constructor is listed as a regiilar
remote method adding void as its retum d u e . This is necessary to rernotely invokv
the appropriate constructor once the remote object has been created (more on t his ici
the HelloWorld class expianation). Note that RMI requires that the remote methods --
lin a Single Program Multiple Data (SPMD) mode!. multiple instancc~ of the samc prograni work on different portions of data. Sec (Wil951 for a cornpletc taxonomy.
1 1 1 - Hello-java ]
package HelloWorld ; import java.rrni.*; public interface HeIloRl extends Rernote {
String Salute() throm RemoteG<ception; void Hello(String - m q ) t hrows RemoteException ;
1
Figure 9.5: Hello World Application: Parallel Version, Remote Interface
be public; the compiler should enforce this by changing the declarations as needed.
After completing the remote interface, the implementation of the class Hello sho~ilcl
be changed accordingly. Note that the changes are simple and can be easily perfornitd
by a compiler (see Figure 9.6). The RemoteException should be addeù to the throw
clause of each method and a neargument constntctot should be provided.
Once the Hello class bas been transformed, the HelloWorld application has to
be modifieci. Figure 9.7 shows the modified version of HelloWorld. The applica-
tion is modified to be executed under the SPMD model. The same code is rut1
on each node; that is the application is separately started up on each nodc wit ti:
java HelloWorld.HelloWorld ranknumbcr. A rank number is added to the applicat iorA
parameters line so t hat different nodes can execute different portions of t hc code ( s w
the rank variable in the code). The RMlSecurityManager is made active and an O b
jectServer is instantiated on each node. Each node creates a Scheduler to hancile t l i ~
placement of the dynamically created remote objects. Then, the code is split usirig
the rank number. The task with rank *Ow (the master task) will be t he only one tu
execute the code inside the *if'' statement. The master task will use the Scheduter
to obtain a reference to an ObjutServer that is running on some remote node. This
reference in turn, is used to create an instance of Hdlolmpl on a remote nocle via
the CreateObjectO method. The appropriate constructor is immediately invoked a
a remote method. Note that the modifications t o the HelloWorld class are extcnsiw
and require significant compiler work. In particulas, each method cal1 to an objrrt
t hat has been made remote has to be surrounded by a tryjcatch clause to handlc t kit.
remote exceptions chat could be generated by the RMI system.
' ~ h i s constructor will be wcd when the remote O b j d e w e r instantiatn this clas
C L 1
//-[ Hellolrnpl .java 11, package HelloWorld; import java.rmi.*; public class Hellolmpl implernmts HelloRl {
private String msg;
// The neargument constructor is added // for the parallel version (explaincd in the tut) public Hellolmpl() throws RemoteException {
super(); 1 public void Hello(String -msg) throws RemoteException {
msg = -msg; 1 public String Salute() throws RemoteException (
return(msg);
1 1
Figure 9.6: Hello World Application: ParaHel Version, Hello Implementation
9.3 Discussion
The prototype runtirne system prrsented in the previous sections can be modifivd
to support caching of the remote object's data ( to increase performance), access tu
static variables and methods, better Id balancing, and object migration.
As explained in Section 6.3. the RMI system does not provide a way for acccssing
t h e instance variables of remote objects. The use of remote interfaces as data typt?i
prevents the access tu the instance vsriablu btcause teables cannot bc defincd in
an interface. This can be solved (as already proposed) by replacing a11 data accesscbs
by remote method invocations. The use of these accessor methods, a priori, suggests
an important performance degadation. To rninimize this performance penalty. t h r
runtirne system could be expanded to support instance caching. ObjectServer ohjects
could be modified to include a hashtable with cached instance variables frorn ttic
different remote objects. Different consistency protocols could be implemented (cg.
write-update, write-invalidate) and, at the very minimum, read-only data should b t b
replicated. The code in the get() and set() methods should be modified accorilirigly
1 - HelloWorld .java ] package HelloWorld; irnport java.rmi.+; import RTS.*; public dass HelloWorld {
public static void main(String argvu) { String rank; rank = argv[argv.length - 11; System.setSecurityManager(new RMIScurityManager());
tv { ObjectServer os = nm ObjectSenrer(); os.lnit(" HELLOWORLD");
1 catch(RemoteException e) (RTS .fail(" OS creation failed . e) ; } Scheduler sched = new Schedukr(" HELLOWORLD" ); if (nnk.quaîs("0)) { // if Master task ...
trV { ObjectServer vos = sched.getOS(); HelloRl h = ( HelloRI) vos.CreateObject(" HelloWorld. Hellolmpl" ); h. Hdlo(" World" ); System .out.println(h.Salute());
1 catch(RemoteException t) {RTS.faiI(" RemoteGcception" . e);)
1 1
Figure 9.7: Hello World Application: P d l e l Version
to contact the local ObjectSeiver for accessing the instance variables. lsenhour [ l s e < ~ i ]
proposed a system for doing this that cm be adapted to our runtime system.
Another possible use of the runtime system is to provide access to static instaiictb
variables and methods. Currently, RMI does not support static instance variables
and methods. A possible solution would be to implementing the static parts of a
class as a single remote object. When the ObjectSewer creates the first instanct* of
a class, it should also create an object to handle the static parts contained in that
class. This object wil l be a remote object whose instance variables and methods arcb
the stat ic instances and met hods of the original class respect ively. Every object of the
original class that is created is given a reference to its static parts. Static rnetho<ls.
can be accessed through this reference as regular remote methods. Access to statir
instance variables should be changed into the appropriate get() and set() mcthods
on the object that implements the static parts of that class. A similar approach has
been taken by JavaParty [PZ971 and their experience can be applied to Our runtinw
system.
The prototype runtime system provides a simple round robin policy for placing
the objects on the different nodes. B e t t u load balancing algorithms could be tried
instead. This will requin that the Schcduler objects be transformed into remotc
objects and remote methods be provided to exchange load information among thth
di ffeten t nodes.
Object migration could also be provided by using the Object Serialization :\PI
provided by Java and the ObjectSemr objects. To migrate a remote object from ont8
node to a different one. its state should be saved and passed from one ObjectServer
object to another. Also. a new exception should be thrown when a remote method cal1
is atternpted to a remote object that ha9 b e n moved to another node. The cornpilc~r
should insert code to handle this exception and redirect the cal1 to the appropriattb
node (i.e. the location of the objects should be handled by the runtirne system ). Tht-
code that handles the exception should aiso update the reference possessed by t l i ~
client. A similar scheme for object migration has been implemented in JavaParty
[PZg?].
Al1 the mentioned extensions to the matirne system will require significant coni-
piler support. The original sequential code has to be extensively modified in orcier to
incorporate al1 these extensions.
9.4 Summary
In this chapter we preseoted an architecture for a prototype runtime system to slip-
port parallel applications written with RMI. An example was used to show how to
modify a sequential program to be executed on several nodes by using the prototy pt-
mntime system. Finally, severai improvements that c m be made to the pro to typ
were discussed.
Chapter 10
Related Work
Several systerns exist that can be coasidered as related work to Java/RMI. Some
of these systems. such as CORBA [OMG95] and HORB [Sat96], present an object-
oriented distributed mode1 similat to Java/RMI. A b , there are some systems that
intend to apply existing paralle1 programming solutions (such as PVM [Sun901) for
the deveiopment of object-oriented p d l e l applications in Java. Examples of this artb
JavaPVM (Thug61 and JPVM [Fer%]. Agent-based technology has also been tried in
systems like Voyager (V09ïj. Finally, there are some systems like JavaParty [PZ971
t hat extend the functionali ty of JavaJRMI.
[t is important to note that since Java is a very active research topic, new systeriis
appear alrnost every week. Even though the functionality of some these systtBnis
overlap with the work presented in this thesis, many of them were not availabk w h t b i i
we started our project.
In this chapter we discuss these systems in the Iight of their possible use for parailrl
programming. The systems are compared against the Java/RMI approach whenevcr
possible.
10.1 CORBA
CORBA [OMC95] is an open standard for application interoperability defined by
the Object Management Group (OMG). In the Object Management Architect urt*
proposed by OMG, every piece of software is represeated as an object. Objects
communicate with each other using an Object Request Broker (ORB). The ORB
provides a mechanisrn by which the objects transparent ly make requests and rrcri ws
responses across heterogeneous languages, tools, platforrns and networks.
CORBA supports a general Interface Definition Language (IDL) that may be
mapped to any implementation laquage. Interface definitions are specified in 1 D 1,
and then stored in an interface repository. Ciients request services through the ORB
by specifying a target object using an object reference. They can inspect interface
definitions in the repository to identify objects' services, and the services' request
and response formats. The ORB supplies naming services to map (server) objtrt
names, marshals cal1 parameters, dispat ches requests to service providen, and rc-
turns translateci service results to the client objects. The ORB interacts with service
providen via object adapter skeletons. Language bindings for the OMC's IDL haw
b e n specified for C and C++ and binding for other Ianguages. including Java. anb
being developed.
Even though CORBA and RMI have many similarities, they diifer in sonie i i i i -
portant aspects. The main differenca arise from the fact that CORBA was designcd
to be language and platform independent wherear RMI assumes a uniform Java-oril!.
environment. In CORBA, code cannot be moved acroas machines because the met hocl
implementations could be in any binary format. In contrast, RMI makes heavy use of
the Java ability to securely download code. Another feature provided by Java/ RSI I
and not present in CORBA is the automatic garbage collection of the remote objects.
Also, in RMI, objects can be p d as parameters; CORBA can pass primitive typtbs.
references to rernote objects, and compositions of these types (structs). but not oh-
jects. In addition, RMI c m p a s and return object types not seen before as long ;LS
those types are subtypes of the declared parameter types.
Consider the satiiple code s t u w u on Figures 10.1 and 10.2. The code in Figtirtb
10.1 defins a generic server that can be used to execute arbitrary computations
launched from other nodes. Ariy class that implements the interface Compute can ask
the server to execute the computation for it. For exarnple, the code in Figure 10.2
calculates the nurnber PI by shipping the computation to a differeat node.
When the server gets an object of type PI as parameter (which it has never s e m
before), it goes and downloads its class in order t o invoke the run() method.
CORBA, this cannot be done because the server could potentially be written in
'This code was written by JavaSoltes Ken Arnold and posted on the Rb11 mailing list.
-
public interface Compute { public O bject ru no ;
1 public interface ComputeServer extends Remote {
public Object runlt(Compute computation) throws Remotebception;
1
// The server object invokes the runo rnethod on any Compute // object thst is p a d to it.
public class ComputeSeweil mpl extends U nicast RemoteObject irnplements ComputeServer {
public Object runlt(Compute computation) { return computation.run();
1 1
Figure 10.1: Computation Server
class PI implements Compute { private int p r h i o n ;
public Object run() { double pi = computePlromehow() return new Dou bk(pi);
public static void main(String0 args) { ComputerSemr xwer = getAComputerServer(): Double pi = sennr.runlt(new Pl(1000)); System.out.println(" PI m m s to be " + pi);
1 1
Figure 10.2: PI Computation
language.
Since parallel applications usually are deployed on homogeneous farms of corii-
puters, the extra complexity of using CORBA is not justified. This is especially t r w
considering that problems like those of collaboraton and exceptions presented in this
thesis affect C O M A in the same way as RMI.
10.2 HORB
HORB (Sat96) is a Java ORB (Object Request Broker) whose characteristics arid
features are very similar to those of RMI. However, the first version of HORB appeared
four months before the announcement of RM 1.
HORB includes many features that are common with RMI such as:
0 Rernote method connection,
0 Object transfer, and
Autornated garbage collection of remote objects.
Some unique features are ako provided such as:
Dynamic object creation,
O URL baseci object naming,
Asynchronous methods,
0 Security by distributed acces control lists,
0 Inheritance support, and
0 Persistence facility (with support for object revivai).
The HORB package consists of the HORBC compiler, the HORB server, and ttic
HORB claw library. This is similar ro RMI but with the difference that the HORR
system is implemented a t the user level. Hence, HORB will run on any platform that
hao a Java interpreter. * 2Note that this is truc for the RMI system included in version 1.1 but was not the c m w h w
Rh11 was provided as an add-on in version 1.0.2.
Figure 10.3: HORB Architecture
The HORB architecture is similar to that of RMI (see Figure 10.3). The skeletoi~s
and proxies are created by the HORBC compiler and are analogous to the skeletocih
and stubs on the RMI system. Note t hat the ORB layer corresponds to the transport
and reference layers of RMI. Looking at t his, i t is clear t hat the Rb!! is a more gcbntd
and extensible system (i.e. it is easier to implement new protocols). However. HOR tl
is stronger than RMI in other aspects.
in general, the HORB system is easier to use because it does not require t h e ~1st-
of remote interfaces. Furthemore, a remote class does not have to inherit froni a
class such as RemoteObjut. The s t u b and proxies inclde code for al! the metho&
defined in the class that is being compiled (in RMI only for ttiose t hat are specifiecl i i i
the remote interface). The inheritance tree of the cl- is rnirrored by corresporidiiig
stub and proxy inheritance trees. A remote object is created by directly instant iat irig
the proxie class generated by the HORBC compiler. For example, if there is a çlass
Semer (which was cornpiled with HORBC), a remote instance can be created with
the following sentence:
HORB supports dynamic object creation so the application can decide where to
create a particular object (e.g. Iocally or remotely). In RMI the remote object has to
be created by other rneans (e.g. manualiy starting up the server) before the client can
invoke a method. In HORB, an application can create a remote object in any node
just by specifying the URL of the remote node. Moreover, local and rernote objects
can be integrated by using interfaces. See the following example:
interface Server {
i n t Cornpute(...);
1
class Server-Impl implements Server {
publ ic i n t Conpute( ... ){ ...) >
Server local - nev Server,Impl(); // neu local object
Semer reutote - new Server,Proxy(url); // ueu remote object
... local .Conpute() ;
remote . Conpute0 ;
The code shows an interface declaation, a clas that implements that interfart.
(Le. ServerJmpl) and a paurible use of that class. Note how an object can be dcclarcd
of type Server, createcl locally or remotely, and then used independently of its location.
Another interesting feature offered by HORB and not present in RMI is asyri-
chronous met hod invocations. For specifying that a met hod should be invoked asy ri-
chronously, the string Async should be added to the method's name. The a s p
chronous version of our example server would look something Like this:
-- - - - .-- - - -
=The use of interfscai I optional in HORB. Its only purpcsc is for attaining distribution triin>- parency.
class Semer {
in t Comput e,Async ( . . . ) {
return value;
For calling the Compute method the stnngo -Request and Receive are used in
the following fom:
server.Conpute-Request( ...); // continue executing here
value = semer. Coipute-Receive (t imeout ) ;
Even though the choice of using speciai rnethod names seems unnatural. it allows
HO RB to introduce new semantics wit hout changing the language. These const riict s
follow the juturr rnechanism discussed in Chapter 7. For chat reason. the prol>lt*rii
that mises when dealing with exceptions and futures also applies to this systeni ( i . ~ .
HORB does not provide anything to handie it differently).
Another interesting feature of HORB is its support for inheritance. In t l i is sys-
tem, inherited methods can be remotely called without any extra declarations. This
constitutes an advance in simplicity over RMI, where the inherited methods have to
be explicitly added ta the remote interface.
In his paper (Sat961, the author of HORB presents a performance evaluation of his
9ygtern compared against RMI. Et is shown that HORB is trro to thrcc tirncs fasrt~~
than RMI.
Limitations of HORB include the impossibiiity of directly accessing the fields of
rernoteobjects (i.e. accessor methods have to be written as in RMI), and that interfacc
inheritance is not supported (a feature in RMI). Also, the serialization provideci in
Java is more flexible and cornplete since HORB does not seriaiize private fields atid
does not support c l a s versioning (Le. objects saved by a clacls should be restored by
the sarne version of the class).
Overail, HORB is a valid alternative to RMI that provides some features that
are missing on RMI. However, some of the problems discussed in this thesis, such as
exceptions and collaborators, still apply to HORB.
10.3 JavaPVM and JPVM
The JavaPVM [Thug61 system dlows prograrns written in Java to use the Parailel
Virtual Machine (PVM) software developed at Oak Ridge Nat ional Laboratory. PV SI
[SunSO] is a set of software tools and libraries that allows the use of a heterogeneoiis
collection of Unix computers ' hooked together by a network as a single large parallrl
cornputer. Using PVM. the aggregate power of many computers can be cornbiried tu
solve large computational problems. The source code for PVM is amilable at no cost.
Because of that, PVM has been compiled on almost every architecture. PVM works
with programs written in C. C++, and Fortran.
JavaPVM extends the capabilities of PVM to Java, allowing Java applications and
existing applications written in C and C++ to communicate with one anothw iisirig
the PVM APL JavaPVM was written using the native method interfaces provicieci by
Java. Essentially. it is a shared library of PVLf functions written in C . a Java objcct
class (JavaPVM), and some C code which bridges the gap from the JavaPVM c h
to the PVM functions. Each function in the PVM API has a conesponding nativt*
method declared in the JaMPVM clas. For example the standard PVM C funrtioii:
int t i d - pvi,mytid(void) is declared as a method in the JavaPVM clasn:
public native int pvm-mytid ()
Using the native methods capabilities provided by Java, this JavaPVM method resiilts
in a C function:
long JavaPW-pvm,iytid(struct HJavaPVM*) -
4Rmntly PVM was portd to the Win32 platform (i-c. Windows 95 and Windows NT)
The implementation of this function provided by JavaPVM calls the actual PVbI
pvmmytido function and returns the result. The code for this function looks some-
thing like this:
long ~ava~VM,pvm-myt id(struct HJavaPVn +hpvm) (
rat=( (long) pm-mytido) ;
>
There are some advantages in using JaMPVM over other communication mecha-
nisms. The PVM mode1 for pardlel prograrnming is well known and people that arc
already familiar with it can directly apply their expertise to Java. Also, existing par-
allel applications written in C , c++ and Fortran can interface with new ones writttw
in Java. This translates into an easier migration path if a language swi tch is desirrd
However, JavaPVM is implemented wing the native methods capability OC Java.
This gws directly against the idea of Java being used as a programming Iangiiagv
for heterogeneous environments. Also, the message passing paradigm supporttd
by PVM (and by extension by JavaPVM) lacks a high-level of abstraction. Furthcr-
more, the communication process in PVM is fully e x p o d to the programmer rvho is
responsible for controlling it (including the rnarshaling of parameters).
A related system, JPVM (Fer961, is an implementation of the PVM virtual machirit-
written in Java. This system d a s not use native methods so it fully exploits Java's
pottability. However, JPVM is not interoperable with other PVM machines becausc
it is an implernentation of the PVM daemon servers rather than an interface betwwii
Java and PVM. This seriously restricts the usability of the systern. JPVM sh.zrr.s
with JavaPVM the same problems regarding abstraction and ease of use.
10.4 Voyager
Voyager [V097] is an ORB entirefy written in Java that allows the developmcnt of
distributed applications using traditional (i.e. RPGlike) remote met hod invocations
and agent-based disttibuted prograrnming techniques. Agents are autonomous object s
'The native methocl interface was used to take advantage of the PVkI virtual machine alrearl!- written.
Vayaqer.startup(6023i ; VSensor vsensoc - new VSen~or(~ipiatlk:7023/transor~~; / / wtrensor allas
Figure 10.4: Remote Object Creation and Remote Method Invocation in Voyager
that can be programmed to accomplish several tasks. Voyager agents have the abili ty
of moving through the network to accomplisb their goals.
Voyager appiicat ions contain an infrastructure t hat allows objects to communicat tm
and move through the network, and severai other support services such as distributcd
garbage collection. Every application is identified by a hoat name and a port acldrns
that is unique to that host (e.g. she~ioodpk:6023). An object residing in one a p
plication can communicate with a remote object (i.e. one that resides in a differerit
application) by creating a virtual version of the remote object in the local rnachinc.
The virtual version of a remote object is cnlled a virtud objcct muid acts as a p r o q
for the remote object (i.e. the e q u i d e n t of a stub in RMI).
Virtual objects are created by instantiating a virtual class. Virtual classes arcb
automatically generated by Voyager from an existing Java class and are named by
preceding the original class name with a *V". Voyager only generates code for th<.
client proxies (i.e. there are no skeletons as in RMI), and the virtual clars generator
( the vc utility) can be used to generate virtual claues from classes for which the
source code is not available (i.e. from the .dass file). This characteristic allows t l w
programmer to generate remote objects from existing third-party libraries.
Figure 10.4 shows two applications: shemroodpk:6023 and ipiatik:7023. The code
in the upper half of the figure creates a remote object by instantiating the class
VSensor (automatically generated by vc from Sensor). The constructor is given the
address of an application where the new remote object will be created and an optional
alias (rsensor) that can later be used t o locate the remote object via the application's
registry. The lower half of Figure 10.4 shows how a message, readTemp0, is forwardecl
from the virtual object to the remote object. Exceptions raised in the remote object
are forwarded back to the caller and re-thrown as if they were local exceptions.
In Voyager, messages are ~ynchmnow by default as in RMI. In addition, however.
Voyager supports one wap messages which return immediately discarding any returrt
value, and futums where the call returns immediately with a placeholder that can be
used later to retrieve the value. It is important to point out, however, that the fittiirt*
mode1 provided by Voyager is similar to those discussed in Chapter 7. Thus. t hr i istb
of futur- in Voyager will suffer from the same limitations regarding exceptions that
we have identified.
Another advantage of Voyager over RMI i s that in Voyager objects can be niovtd
from application to application. This is done by simply sending the message move()
to t h e object that needs to be rnoved, and specifying the destination as a pararnetïDr.
When an object is moved to another application. it leaves a s e m t a r y object in its
original application. When a message for an object that has been moved arriv- to
an application, the secretary is contactecf to find out the object's new locatiori arid
the message is au tomat id ly forwarded to it. When the object finally receivrs th<-
message and responds, it includes its new aûdress in the return value so the callt-r
locatc it dimctly in future requeata.
Voyager also supports agent technology. Agents can be created by extending thr
class Agent and then using the vc utility to create a virtual agent class that, in turri.
can be utilized t o instantiate an agent object and communicate with it. Agents can
also be moved €rom one application to another but unlike remote objects. agrrits
can move independently (i.e. they can decide where to go when and they move by
themselves). An itinerary for an agent c m be programmed by specifying an extra
call- back parameter in its move() method. For example:
public void goShopping() 1 move ("storsOne : 3030" , "atStoreOneW) ;
1
The preceding code specifies that whenever the agent receives the cal1 goShop-
pingo, it will send itself the message move(). Ir also specifies that after the agent
has moved to its new location it wiU receive the cd1 atStoreOne0. Note that once
the agent performs the required computation at its new location, the method atStore-
One() can be used to move the agent to another location (i.e. forming in this way an
i tinerary ).
An agent can also be moved to the location where another object resides. This
ability can be used to increase the performance when the agent has to interact hcavily
with another object. Instead of using remote cails, the agent can be told to rnovr. tu
the same location of the other object and perform dl the interactions locally.
Ovedl, Voyager is a more capable sy~tem than RMI. It provides many featitrt*~
like object movement and agents which u e not present in RMI. Voyager ad& asyri-
chronous messages, although the problem presented by exceptions when combinrd
with futures is not even mention4 in the documentation. Also. the performance of
Voyager is much better than that of RMI. See (VR97j for an exhaustive comparisoii
between Voyager an RMI.
10.5 JavaParty
JavaParty [PZ971 is a system that targets the development of object-oriented paralld
appIications ninning on ciusters of workstations using Java and KMI. T h e prograni-
mer tums a multi-threaded Java program into a JavaParty program by inclicatinp:
which classes and threads should be made remote. This is done by using a ncw
modifier remote added to the laoguage.
Figure 10.5 shows how a JavaParty program is translated into Java bytecoclm.
The code is first nin through a compiler that transiates the JavaParty code (i.e. thc
remote declarations) into Java/RMI code. Then the nomal Java and RMI conipil~rs
are used to obtain the final bytecodes.
Figure 10.5: JavaParty Code Translation
JavaParty provides several advantages over the use of RMI done. It abstracts
the programmer from the compiexitia of RMI (e.g. declaring met hods in the rrniotv
interfaces and catching extra exceptions). As a consequence. the code written hy t lit.
user when using JavaParty is shorter than the equivalent RMI version (although t h *
code generated by JavaParty is much longer).
JavaParty dso provida object migration (although, in fact. objects can 0111- h t ~
moved when t hey are not executing any method), and avoids the RMI overhead w h i
objects reside on the same virtual machine (which is a very important perfornianw
consideration). Another added featun in JavaParty is the ability to access cla~
variables and methods (i.e. static fields and static methods). In RMI. these stat ic
parts cannot be accessed.
Besides the compiler. the JavaParty system includes a runtime system ttiat is
used to support itccess to the static parts of the classes and the migration of objects.
This mntime system consists of a centrai component that is unique to the systerii
and a local manager per node. The central manager knows ail the local managprs
and the location of dl the objects that implement the static parts of a class. :\II
this information is replicated in the local managers to reduce the load on the central
manager. Objects are created according to distribution strategies t hat can be selcr ted
and changed at runtime.
JavaParty is a good alternative to Java/RMI alone. In fact, it solves some of
the problems of RMI and provides an eapier model to write parallel applications.
Even though some of the problems of RMI still remain, JavaParty constitutes a step
forward over RMI. The ability to access the static parts of a class is an important
feature for the development of automatic parailelization tools since class variables and
met hods are present in almost every sequential program. A h , given the performance
of the RMI system (see Chapter 5 ) , the optimization of message invocations betwerii
remote objects that reside on the same machine is extremely d u a b l e . Finally, the
object migration facility provideci by JavaParty provida a more flexible dist ribii t ion
model (i.e. the placement of the objects can be dynamically changed).
10.6 Summary
In thia chapter, some approaches to object-oriented parallel applications were dis-
cussed. CORBA and HORB were described as having rnodels of object distribiitioii
similar to RMI. JavaPVM and JPVM were presented as examples of a different ap-
proach that is closer to socket programming than to object distribution. Agent- hasi~l
approaches were illustrated with the Voyager systern. Finally, JavaParty was show r i
as a system that is based on the Java/RklI model but that extends that niodcal t~
include some important features for parallel programming.
Chapter 11
Conclusions
This thesis is an evaluation of Java and RMI for the development of object-orientrd
parallel applications. in particular, the thesis looks at the issues involved iri autw
matically dist ri buting sequential objectsriented programs by using a parallclizi ng
tool. The focus is placed on how the featuns of the language. the object-orientt4
technology used, and the parallelization techniques applied can be combined for t h t b
development of distributed applications.
While some of the i s s u a rsised in this t h a i s can be directly related to th<-
Java/RMI design, others are intrinsic to the object-oriented paradigni used in t l i t*
programs, and some others to the pardiel computing model.
The problems directly related to Java/RMf identifid in this thesis includr:
Lack of transparency: The RMI system forces the programmer to declare rvhich
methods can be remotely called by the use of remote interfaces (including t h ~
class' methods and any inherited methods as well). Also, cl- are reqoirrd
to implernent the Serializable interface so that their objects could be used as
parameters or return values of remote methods. Furthemore, al1 the rcrnotr
methods should be public. As shown in this thesis, this lack of transparency of
the RMI system can be overcome by the use of extensive compiler transfornia-
tions ( to adapt the user's code to the RMI syntax), and by some changes in t ht*
implementation of the RMI system itself (e-g. the elimination of the Serializable
requi remen t ) .
Performance: The RMI system proved to be a major bottleneck. The perfornianw
evaluation in Chapter 5 showed the huge overhead incurred by the applicatioiis
when using RMI. This overhead is caused by the complexity of the differcrit
layers of the RMI system (i.e. stubs/skeletons, reference and transport ). Fiir-
thermore, a decompilation of these layers also reveded the presence of debiig-
ging code. The serialization routines, even though they can be optimized, were
not as inefficient as RMI itself. It is clear that a method must have a large
ganularity to offset the overhead of the RMI system.
Access to instance variables: RMI does not provide a way of accessing the in-
stance variables of the remote objects. Compiler transformations could be ust4
to overcome thia limitation. As discussed in Section 6.3, a solut ion is to changt*
al1 the accesses to instance variables into calls to appropriate get() and set()
remote methods,
Access to static instance variables and methods: As pointed oitt in Chaptvr
3, static instance variabla and methods caanot be used with RM1 alone. Tliis
happens because clients only see what is declared in the remote interface of ari
object and the static keyword is aot allowed inside interfaces. .4 runtimc systerii
is needed for supporting access to remote static variables and met hods.
Even though these problems affect the automatic paralleiization of the user's s r -
quential code, t hey can be solved by using compiler transfomat ions and a riint inii*
system. A prototype system that addresses many of these concerns was desçribcd
in Chapter 9. The performance overhead, however, constitutes a very strong fartur
against the use of RM 1 as the target of out parallelizat ion tool. If RM 1 is used direct 1)-
by the user, the performance degradation is partiaily compensated by i ts ease of tiscD.
However, when using a parailelizing tool, it is preferable to generate the fastest cocltb
that is poasible because the ease of use will aiready be provided by the environment.
that is, the user will write sequential programs.
Regardless of the communication mechanism used (e.g. RMI, sockets. etc.). this
thesis identified some harder problems which are not caused by JavafRMI siich as:
Exceptions: As demonstrated in Chapter 7, the exception handling mechanisni5
included in some modern languages, such as Java and C++, can seriously liniit
the amount of concurrency in a parallel application. hlthough we prt?ienttd
some approaches for deaiing with this problem, further research will be necrssary
to find solutions that provide better performance.
Collaborators: Chapter 8 showed the problems that any objectsriented language
with dynamic dispatching can present for detecting the collaborator set. This
issue requires further work for the development of a t w l to automatically de-
termine the collaborator set.
The ooly problem related to the paralle1 computing mode1 is how to stop a run-
ning computation in a speculative computing environment where severai futures are
created to tind or compute the same value. As sbown in Chapter 7 this can be solved
by providing an extra method in the server or in the future (according to which irii-
plementation of futures is used) to stop the appropriate thread. This problem do-
not constitute an important impediment for the development of a parallelization tool
as its solution is straightforward.
Because of the problems explained above, we conclude that any automatic par-
allelizing tool for an object-orienteci language will have to deal with the issitt?i uf
exceptions and collaborators. RMI, in addition, presents many problems that ran IN@
addresseci as dixussed in this thais. However, given its perbrmance. WC also cuii-
clude that the amount of compiler support needed to address d l these problems is too
large compareci with the benefits obtained by using the RMI system. Even thoiigti
RMI c m be successfully applied to other domnins, such as distributed client/serwr
databases where the performance overhead of the RMI system is not a predominant
factor, it is unsuitable for being wed as the underlying communication paradigm of
our paraileIizing tooi.
Bibliography
Piem America. 'POOLT: A Pardel Object-Oriented LangiiagrW.
Object-Oriented Concurrent Programming, MIT Press, 1981.
G. Agha and C. E. Hewitt. 'Concurrent Programming Using Actorsw.
Object-Orient4 Concurrent Programming, MIT Press, 1987.
P.A. Buhr, C. Ditchfield, R A . Stroobosscher. B.M. Younge. and C'.R.
Zarnke. *pC++: Concurrency in the Object-Oriented Language C'+ + ' . Software: Practice and Experience, vol. '22, no. 2, pp. 13% 172. 1992.
Adam Beguelin. Jack Dongarra. Al Ciest. Robert Mancheck. and Iiei t l i
Moore. 'HeNCE: A Heterogeneous Network Computing Environtricnt".
Technical Report UT-CS-93-205, University of Tennessee. .4ugust 1!)93.
Henry Baker Jr. and Carl Hewitt. T h e Incremental Carbage Collectiori
of Processes". Proceedings of the Symposium on Artificial Intelligence arid
Programming Languages, pp. 5859, Augwt 1977.
A. D. Birrel and B. J. Nelson. *Implementing Remote Procedure ('ails-.
XEROX CSL83-7, October 1983.
B.J. Cox. "Object Oriented Programming - An Evolutionary Approach".
Addison- Weeley, 1986.
Jason English. 'It al1 started with a blunt letter". Java FAQ, Sun Mi-
crosystems Inc., 1997. ht tp://www.ja~soft.com/nav/whatis/index. ht ml
Adam Ferrari. "JPVM"
http://www.cs.virginia.edu/~ajf2j/jpvrn.hl
[Fla96] David Flanagan. "Java in a Nutshell". O'Reilly k Associates, Inc. Febrii-
ary 1996, First Edition.
[Gri93] A. S. Grimshaw. "Easy to Use Object-Oriented ParaIlel Programming witli
Mentatw. IEEE Computer, vol. 26, no. 5, pp. 39-51, May 1993.
[GH+94] E. Gamma, R. Helm, R. Johnson and J. Vlissides. "Design Patterns: Elc
ments of Reusable Object-Oriented Software". Addison-Wesley, Reading.
Massachusetts, 1994.
[GJS96] James Gosling, Bill Joy, and Guy Steele. The Java Language Specifiîa-
tion". Addisson- Wesley Java Series, September 1996.
[GM96] James Gosling and Henry McCilton. The Java Language Environmen t:
A White Paperw. Java White Papers. Sun Microsystems Inc.. 1996.
ht tp://www.javau>ft.com/nav/read/whitepapers.htmI
(GR831 A. Coldberg and D. Robson. 'Smalltaik 80: The Language and i ts Iniplt*-
rnentationw . Addison- Wesley, May 1983.
[Hal851 Robert Halstead. 'Muitilisp: A Language for Symbolic Compu tat ionu.
ACM Transactions on Programming Languages and Systems. Octobt-r
1985.
[Ham961 Marc A. Hamilton. "Java and the Shift CO Net-Centric Computing'. ('oni-
puter, pp. 31-39, August 1996.
[HCLr91] L.. Holzfe. C. Chamben and D. Ungar. 'Optirnizing Dpamically-I'ype~l
Object Oriented Languages with Polymorphic Inline Caches*. ECOOP 9 1.
Conference Proceedings, 199 1.
[Ise971 Pbilip Isenhour. "Property Cachiag for Remote Java Objects" .
http://simon.cs.vt .du/ kenhour/rmicache/
[JO951 "The Java Language: An Overviewn. Java White Papers. Sun Milicrosys-
tems, Inc., 1995. http://www.javzwft .com/nav/read/whitepapers. htrnl
[Kra961 Douglas Kramer. "The Java Platform: A White Paper". Java White Pa-
pers, Sun Microsystems, Inc., 1996.
ht tp://www.javasoft.com/nav/read/whitepapers. html
[Lot381 V. M. Lo. "Heuristic Algorithm for Task Assignment in Distributecl Sys-
temsn. IEEE Transactions on Cornputers, vol. 37, no. 11, November 198s.
[MPI94] Message Passing interface Forum. 'MPI: A Message-Passing In te r fac~
Standard". May 5, 1994. University of Tennessee, Knoxville. Report ?io.
CS-94-230. See dso: International Journal of Supercom put ing A pplica-
tions, vol. 8, no. 3/4, 1994.
(Nie871 Oscar Nierstraz. 'Active Objects in Hybrid". OOSPLA '87 Procectiings.
ACM SIGPLAN Notices, vol. 22, no. 12, pp. 243-253. December. 1987.
[NH85] L. M. Ni and K. Hwang. 'Optimal Load Balancing in a M~lt ipro~essor
System with Many Job Classes". IEEE Transactions on Software Engi-
neering, vol. S E 1 1, no. 5, May 1985.
[OMC95] O bject Management Croup. T h e Cornmon Object Request Broker: Ar-
chitecture and Specification" . Revision 2.0. July 1995.
[OS961 "Java Object Serialization Specification". Sun Microsystems, Inc.. 1996.
[PZ971 Michael Philippsen and Matthias Zenger. "JavaParty - Transparent Rv-
mote Objects in Java". University of Karlsruhe, Cermany.
[RMI97j *Java Remote Method Invocation Specification*. Revision i ..t . J D K 1.1
FCS, February 10, 1997. Sun Micrmystems, Inc., 1997.
[SunSOj V. Sunderam. 'PVM: A Framework for Paralle1 Dist ri buted Corn put ing' .
Concurrency: Practice and Experience, 2(4):3 15-339, December 1990.
[Str91] Bjame Stroustrup. *The C++ Prograrnming Language" . Addison-H'cslt-y.
Reading, Massachusetts, second edition. L991.
[Sat96] Hirano Satoshi. "HORB: Distributed Execution of Java Programsu.
ht t p://ring.et l.go.jp/openlab/horb/
Duane Szafron and Jonathan Schaeffer. "An Experiment to Measure t hc
Usability of ParaIIel Programrning Systemsn. Concurrency: Practice atitl
Experience, vol. 8, no. 2, pp. 147-166, 1996.
Jonathan Schaeffer, Duane Szafron, Creg Lobe and Ian Parsons. 'Thtb
Enterprise Mode1 for Developing Distributed Applications". lEEE Parallel
and Distri buteci Technology, 1 (3):8596, 1993.
David A. Thunnan. 'JavaPVM vl.0. L n
h t t p://homer.isye.gatech.edu/chmsr/JavaP/
A. N. Tantawi and D. Towsley. "Optimal Static Load Balancing in Dis-
tributed Computer Sptems". Journal of the ACM. vol. 32. pp. 44.5--16.3.
April 1985.
'Voyager Core Package Technical Overview". Voyager White Papers. O 1)-
jectspace. Inc., 1997.
http:// www.objectspace.com/Voyager/voyager~white~paperr. h t ml
Voyager and RMI Cornparison". Voyager White Papers, O bject Spaw.
Inc., 1997.
http:/ /www.objectspace.com/Voyager/voy~papers= htmi
Peter Wegner. "Dimensions of Object-Based Language Design'. Proceed-
ings of the Conference on Object-Oriented Programming Systems. Lati-
guages, and Applications (OOPSLA), in SICPLAN Notices vol. 2. no.
12, pp. 168-182, December 1987.
Gregory V. Wilson. "Practicai Pardel Programming". MIT Press. Scicn-
tific and Engineering Computation Series, 1995.
Murray Wwdside and Gerdd Mon forton. '<Fast .4liocation of Process i ri
Distributed and Parallel Systems". IEEE Transactions on Parallel and
Distributed Systems, vol. -1. no. 2. February 1993.
[YTS?] Y. Yokote and M. Tokoto. 'Concurrent Programming in ConcurrentS-
malltaik" . O bject-Oriented Concurrent Programming, MIT Press, 1987.
