INRIA CNRS I3S Univ. of Nice SophiaAntipolis

1
JavaGrande, ProActive PDC, and Java in
Distributed Computing

• Denis Caromel
• INRIA -- CNRS - I3S -- Univ. of Nice
  Sophia-Antipolis
• caromel_at_unice.fr

1. Java for HPC 2. ProActive PDC 3. Conclusions,
perspectives JINI
2
Java for HPC, PSE ...Why such a (strange) idea
?

• Some unique features of the Java technology
• Cross-platform portability actual architecture
  encapsulated within the VM. Ease
  Grid-programming.
• Good language secure, safe, object-oriented,
  multithreaded, familiar to C, C
• Very good set of libraries network, multimedia,
  images, maths,...

3
What about performances ?

• Standard Java is (was) painfully slow for HPC
• Interpreters are simply not good for
  high-performance computing
• JIT compilers still suffer from too many runtime
  checks
• Optimized Java gets close to C and Fortran
• Optimizing compilers remove unnecessary checks
• Proposition made to Sun to better use the
  underlying floating-point hardware
• Execution techniques are improving
• HotSpot virtual machine Java code can even
  adapt itself to the data at runtime

4
Why standard Java is slow

• for (int i0 i
• for (int j0 j
• for (int k0 k
• Cij Aik Bkj
• For each iteration of the inner loop
• 3 pointer checks
• 6 array bounds check
• Standard Java is more than 100 slower than
  Fortran !

5
A way to optimize Standard Java

• if (( m
• (m
• (n
• for (int i0 i
• for (int j0 j
• for (int k0 k
• Cij Aik Bkj
• else
• for (int i 0 i
• for (int j 0 j
• for (int k 0 k
• Cij Aik Bkj

Java is now less than twice slower than Fortran !
6
Java Grande Forum

• Not a standardization body for Java
• But the unified voice of the HPC community to
  communicate input directly to Sun or some
  prospective Java standards group
• --- Advises and pressures
• Includes academics, industrials (IBM, Sun, Intel
  ...), US government agencies and laboratories
• Issues recommendations for changes to Java and
  standards
• Academic Coordinator
• Geoffrey C. Fox (Syracuse Univ. And NPAC)

7
Java Grande Forum (2)

• Two working groups
• Concurrency, Distribution, Applications
• Co-Chairs
• Denis Caromel (INRIA - Univ. Of Nice - Sophia
  Antipolis)
• Dennis Gannon (Indiana Univ. - NASA AMES)
• RMI and Serialization performances
• Standard benchmarks
• Standard Java binding for MPI
• Numerics
• Co-Chairs
• Ronald Boisvert (NIST)
• Roldan Pozo (NIST)
• Floating-point semantics, Complex class
• Operator overloading, Lightweight objects,
  Multidimentional arrays
• Math libraries (arbitrary precision, BigDecimal)

8
Java Grande Forum Numerics

• Floating-point semantics
• Problem incompatibility between
• High predictability of results
• Aggressive use of floating-point hardware
• New proposal from Sun (JG inputs)
• 2 floating-point modes default and strictfp
  (classic Java)
• Still not enough no FMA (floating-multiply-accumu
  late) a c b
• New proposal from JG to allow use of FMA
• strict results exactly reproducible
• default results highly reproducible
• extended not reproducible, but high performance

9
Java Grande Concurrency, Distribution

• RMI
• Serialization is too slow
• RMI architecture is not open
• layers are coming (JG inputs)
• but not documented, no source code available
• Instable or slow network assumption
• Java Grande acts for
• An open RMI architecture (Serialization, Class
  loading, Transport)
• DROP-IN replacement
• Support for custom transport (non-TCP/IP,
  Myrinet, ...)
• Customizable Serialization
• HP assumption (e.g. closely connected cluster)
• Efficient test implementation (e.g. M.
  Philippsen, Karlsruhe)

10
ProActive PDC Objectives and Rationale
Seamless
Sequential
Multithreaded
Distributed

• Most of the time, activities and distribution are
  not known at the beginning, and change over time
• Seamless implies reuse, smooth and incremental
  transitions

Library !
11
ProActive Objectives and Rationale (2)

• RMI a step in the right direction
• Language-centric, syntax, easy to use, safety,
  portability, reuse
• However, a few limitations
• Because not all Java types are interfaces
  (classes can be types)
• Because classes implementing Remote need to
  extend RemoteObject
• Reuse is not as good as it could be
• Integration with threads is not seamless
• Moreover, other models of parallelism are needed
• Asynchronous calls, synchronization, MIMD, BSP,
  SPMD, Active Objects

12
ProActive model

• Active objects coarse-grained structuring
  entities (subsystems)
• Each active object - possibly owns many passive
  objects
• - has exactly one thread.
• No shared passive objects -- Parameters are
  passed by deep-copy
• Asynchronous Communication between active objects
  
• Future objects and wait-by-necessity.
• Full control to serve incoming requests
  (reification)

13
ProActive Architecture

• ProActive is simply a library, not a new language
  or environment
• 100 Java
• No special compiler, no source preprocesing
• No special virtual machine or modification to the
  standard libraries
• Implementation based upon
• Generation of stub classes (at runtime if needed)
• Use of Java RMI (Remote Method Invocation) as a
  distributed object library
• Wherever Java runs, ProActive also runs

14
ProActive Active object
Standard object

• An active object is composed of 3 objects
• The object itself (1)
• The body handles synchronization and the
  service of requests (2)
• The queue of pending requests (3)

1
Objet
Active object
Proxy
Object
1
2
Body
15
ProActive Creating active objects
Single inheritance using interface

• An object created with A a new A (obj, 7)
• can be turned into an active object
• Class-based
• class pA extends A implements Active
• A a (A)ProActive.newActive(pA,params,
  node)
• The most general case. Allows to provide a
  specific behavior.
• Instanciation-based
• A a (A)ProActive.newActive(A,params,
  node)
• Object-based
• A a new A (obj, 7)
• a (A)ProActive.turnActive (a, node)

16
ProActive Reuse and seamless

• Two key features
• Polymorphism between standard and active objects
• Type compatibility for classes (and not only
  interfaces)
• Needed and done for the future objects also
• Dynamic mechanism (dynamically achieved if
  needed)
• Wait-by-necessity inter-object synchronization
• Systematic, implicit and transparent futures
• Ease the programming of synchronizations,
  and the reuse of routines

17
ProActive Intra-object synchronization

• Explicit control
• Library of service routines
• Non-blocking services,...
• serveOldest ()
• serveOldest (f)
• Blocking services, timed, etc.
• serveOldestBl ()
• serveOldestTm (ms)
• Waiting primitives
• waitARequest()
• etc.

class BoundedBuffer extends FixedBuffer
implements Active live (ExplicitBody
myBody) while (...) if
(this.isFull()) myBody.serveOldest("get
") else if (this.isEmpty())
myBody.serveOldest ("put") else
myBody.serveOldest () // Non-active wait
myBody.waitARequest ()
Implicit (declarative) control library
classes e.g. myBody.forbid ("put", "isFull")
18
ProActive Conclusion

• 100 Java
• Both parallelism, distribution, and sophisticated
  synchronization (CSCW)
• Multithreaded and distributed
• Mapping of active objects onto hosts and VMs
• Reuse -- seamless
• Polymorphism with existing class types
• Dynamic works on previously unknown objects and
  classes
• Asynchrony -- Wait-by-necessity
• Centralized control
• ProActive vs. RMI alone - 30 of code
• www.inria.fr/oasis/ProActive

19
C3D distributed-//-collaborative
20
DIVA Distributed Int. Virtual World in Java
21
Perspectives Jini ?

• Smart devices everywhere, are going Java
• Difficult to install, configure and inter-operate
• Jini technology devices can - self-install,
  self-configure,
• - be discovered
• Enabled by
• Javas platform independence,
• dynamic class loading, mobile code (RMI)
• security features

22
Perspectives Jini - The Architecture

• An infrastructure and a programming model (rather
  interaction)
• Jini uses Java RMI for moving code and messages
  around
• Basic services
• join, register, lookup, etc.
• For a certain time leased proxy (instable
  network)
• APIs to
• distribute events
• object brokering
• transaction management
• share information

23
Conclusion

• Is Java suited for HPC - PSE ?
• First real-life experiments are encouraging
• Java has unique features for HPC (platform
  independence, Jini, HotSpot, ...), without any
  clear alternative
• Still a long way to go but
• RMI call end of 98 50 ms, mid 99 80
  micro s.
• Want to know more ?
• www.javagrande.org
• www.inria.fr/oasis/proactive

24
www.inria.fr/oasis/ProActive