Aspects of Portability and Distributed Execution for JNIWrapped Code - PowerPoint PPT Presentation

Title: Aspects of Portability and Distributed Execution for JNIWrapped Code


1
Aspects of Portability and Distributed Execution
for JNI-Wrapped Code
Paul Gray and Vaidy SunderamEmory University,
Atlanta, USAgray,vss_at_mathcs.emory.edu
Vladimir Getov, University of Westminster,
London UK

• Overview
• Collaborative system for metacomputing in
  heterogeneous network environments
• Framework based on process/data mobility and
  dynamic merging/splitting of resources

2
Visions for Metacomputing-scale Distributed
Computations

• Would like to be able to run any component of the
  distributed computation among any of the
  platforms in the heterogeneous composition of
  resources.
• Would like to permit processes to utilize unowned
  resources those of a colleague, in another
  department, at another laboratory, etc.
• Would like to have a dynamic resource pool.

3
Motivation

• High-performance computing is moving towards
  clusters, while maintaining a cordial
  relationship with parallel architectures.
• Programs are coming into existence which exist in
  dynamic, multiple phases.
• (TENT example)
• partition
• CFD computation
• post process, post process, post process,
• Collaborative sharing of tools/data/resource.

4
The Objective
Update Database, Post-process data
5
Utilization of Unowned Resources

• How should the program components be introduced
  for execution on unowned resources?

• In PVM and MPI paradigms, the user provides the
  static binary form of the executable by NFS, ftp,
  etc. Too restrictive for metacomputing.

• Automated ftp-like uploading of files could
  provide the needed program components to remote
  systems, but still requires giving access to the
  filesystem.

6
Metacomputing View Summary

• Concurrent Computing
• merging and splitting of multiple virtual
  machines
• portability of code and data, uploading, soft
  install and migration
• Multilanguage support to include Java, C, C,
  and Fortran.
• Message passing supported paradigm for parallel
  and distributed computing

7
Implications

• Collaborative programming environment.
• Provisional access to computational resources
  beyond local networks.
• Data mining (send processes to the data).
• Optimal process mapping.
• Nomadic virtual environment.

8
The Role of Java in Metacomputing Design

• Consider the aspects of the Java programming
  language which appeal to this view of
  metacomputing
• Standardized bytecode representation.
• ClassLoader mechanism.
• Built in, extendable, security management.

9
Initial Implementation The IceT Environment

• Java-based message-passing substrate with Java
  programming bindings.
• Commands such as add, delete, spawn, kill, and
  similar PVM-style commands to dynamically
  configure the environment.
• Additional commands to merge, split and register
  virtual environments.

10
Functionality...

• The Java-based implementation proved to be well
  suited for computationally-lite distributed
  computing tasks across network boundaries.
• Although speedups were observable for
  parallelization of tasks over clusters,
  performance for traditional distributed computing
  tasks left a lot to be desired.
• A LOT to be desired!

11
Why So Slow?

• Java-based communication substrate for message
  passing.
• Raw Speed of execution.

12
Communication Woes

• Lack of pointers extra effort
• Cannot simply cast the contents of a message
  buffer into the desired structure. Instead
• Instantiation of an object to absorb the buffers
  contents (bad, malloc overhead).
• wrap byte array into ByteArrayInputStream
• or, manual memory to memory copy/casting/ masking.

13
Speed of Java(Oxymoron, better Javas
Mega-Flop Performance)
( shorter bars are better )
14
Computational Performance

• Java has yet to be established as a viable
  language for High Performance Computing.
• Interpreted bytecode representation wonderful for
  heterogeneous execution detrimental to execution
  speed. (Enter JIT.)
• Lack of IEEE floating point standard. Things
  like extended double hardware is inaccessible to
  Java programs (such as the IEEE 754 double
  extended precision, or long double)!
  Computational reproducibility at the cost of
  speed, precision.

15
Solution Blend Java with C/Fortran

• Use Java for the initial introduction of the
  program collective to the remote host. The
  wrapper class may be analyzed for class
  dependencies, shared library usage, security
  violations, etc.

• Use C/Fortran codes as the computational engine
  of the process. Compiled into shared libraries
  (.sos or .DLLs), they can be encapsulated
  within the program collective and loaded onto the
  remote resource.

16
The (New) Objective
17
Benefits of Native Code Use

• Can permit integration of legacy codes and
  scientific packages.
• Increase (often significant) in computational
  performance.

18
Legacy Codes andSoftware Packages

• By facilitating the soft-installation of native
  code, software already written to utilize
  established and time-tested high-performance
  packages can be incorporated into the IceT
  metacomputing environment.
• Platform-specific tuning permits high-performance
  computing and a more optimal process mapping.

19
Are All Attributes of Java Lost?

• Program collectives with native codes are still
  highly portable, because the interface to native
  code is very well defined.
• Implication
• One can dynamically re-configure the
  metacomputing environment to suit applications
  needs.

20
Reconfiguring the Environment
Example
Swapping out the underlying communication layer
in a numerical computation.
Times (in milliseconds) required to send/receive
a double-precision array.
Using IceT, the Java-based communication layer
was swapped out for the more efficient CCTL. The
result is high-performance and portability.
21
JavaMPI

• The LAM version of MPI was wrapped using the JCI
  (Java-to-C Interface), a separate and ongoing
  effort by V. Getov and S. Minchev (Univ. of
  Westminster).
• IceT demonstrated the ability for a user to
  write/debug applications using the local MPI
  package. Once tried and true, the user may use
  IceT to upload and install the applications on
  any number of remote pre-configured MPI
  environments, swapping out MPI library cores as
  appropriate.

22
In a Nutshell
Java Bytecode ...2212EBABEFAC
libJavaMPI_MPI.so ...010011101011010
23
How does IceT load native code?

• Native code must be wrapped in a Java front end
  using the Java Native Interface (JNI).
• This front end is analyzed. The analysis
  consists of a parsing of the static bytecode
  which allows extracting of the name(s) of the
  native libraries needed.
• The local IceT daemon secures the appropriate
  version of the shared library and links it with
  the process.

24
A Simple Example of the Bytecode Analysis
static System.loadLibrary(cctl)

• Reconstruct constant pool.
• Reconstruct Methods opcode instruction set.
• In the (ltclinitgt) method, we find these six
  bytes 0x12, 0x0B, 0xB8, 0x00, 0x12, 0xB1

Constant Pool Item 11 (cctl)
ldc
Invoke static method
Return
25
Pertinent Details

• This analysis is performed in an IceT classloader
  found on the remote host, configured by the owner
  of the resource.
• Not recoverable through catching of an
  UnsatisfiedLinkError or through the Java
  Reflection class.
• Denial of service by static analysis (next
  slide). Execution governed by SecurityManager.

26
Additional Benefits

• Can detect any method invocations which allows
  the owner of resources to tailor the environment
  to allow/disallow specific calls.
• Can detect all of the class dependencies and
  analyze them recursively all prior to
  instantiation. (compare to browsers)
• Can detect all of the required shared libraries
  security, establish environment.

27
IceT Summary and Status

• IceT continues to develop and to extend a
  particular niche in metacomputing, giving proof
  of concept to Javas benefits to HPC.
• With the mixing of Java and native codes, IceT
  continues to show that program collectives are
  able to exhibit a high degree of portability and
  are able to maintain high performance.

28
IceT Summary and Status

• Needed Investigations into unloading/reloading
  components.
• Needed Efficient, robust, Java-based transport
  layer, with reliable, unreliable, atomic,
  multicast, etc. Until then, JNI-wrapped codes
  such as JavaMPI, and JNI-wrapped CCTL are clear
  choices for HP I/O.