JOrchestra: Automatic Application Partitioning

1
J-Orchestra Automatic Application Partitioning
http//j-orchestra.org

• Yannis SmaragdakisEli TilevichDean Pu Mao
• Austin (Chun Fai) ChauKane SeeHailemelekot Seifu

2
Automatic Application Partitioning?

• Application Partitioning breaking up an
  application into pieces that run on different
  network locations
• e.g., sensor inputs are controlled by one
  machine, data processing is done on another,
  storage is handled by a third
• Automatic Application Partitioning instead of
  rewriting an application by hand, have a tool
  handle all the details under human guidance

3
J-Orchestra

• Given any centralized Java program (in bytecode
  format) partition it
• make distribution decisions about the program
  components
• possibly with some user input
• taking into account the results of static
  analysis
• automatically rewrite the program so that it runs
  with some middleware mechanism (e.g., Java RMI,
  CORBA, etc.)
• only the program changes, not the VM/system code

4
Example
DB
Program as a sea of classes
sensor
UI
5
Benefits and Competition

• The benefit is very significant no need to
  partition programs by hand
• application partitioning is a major need in the
  internet era
• imagine an alternative to applets, servlets,
  X-Windows, telnet, more
• think of the embedded systems applications
• J-Orchestra is by far the most powerful
  auto-partitioning system
• others exist but have severe limitations in how
  they can partition applications

6
3 Main Elements of Approach

• Powerful back-end
• can partition along any application and many
  system class boundaries
• Profiling
• estimate data coupling during a run of the
  program
• Static analysis
• used for separating system classes, optimization

7
J-Orchestra back-end What makes it special!
http//j-orchestra.org
8
Where is the magic?

• It may seem like the issue is just a small matter
  of programming
• just change all method calls and direct field
  access to RMI calls, do bytecode rewriting to
  make all objects remotely invokable
• For every complex problem there is a solution
  that is simple, elegant, and wrong
• doesnt work because of aliasing! Objects on
  different locations may be sharing data through
  references

9
Call-by-copy

• RMI semantics call-by-copy
• the entire state of the system reachable from a
  parameter is passed by value
• arguments are serialized recursively and copied
  over the network
• copies are not kept consistent, changes do not
  propagate back

10
Example remote call foo(p)
p
p
alias2
alias1
11
Example remote call foo(p)
changes never make it back!
p
p
alias2
alias1
12
What if...

• We can keep the objects only on their creation
  site and make them remotely accessible (using
  bytecode rewriting)

p
p
alias2
alias1

• Very inefficient (no mobility) and limited (w.r.t
  native code)

13
Solution

• We can change all references from direct to
  indirect (through proxies)

p
alias2
alias1
14
Solution

• We can change all references from direct to
  indirect (through proxies)

p
alias2
alias1
15
Solution

• Proxies hide the location of the actual object
  objects can move at will to exploit locality

Site 1
Site 2
p
alias2
alias1
16
Details

• Proxies
• retain the method interface of the original class
• delegate all calls to potentially remote sites
• Remote objects
• binary modified original classes to understand
  RMI
• serializable, no direct access to members

17
The fun has just begun

• What about system classes?
• other system classes (e.g., native code) rely on
  accessing them directly
• e.g., native code is compiled to a particular
  object layout, like accessing a field at a
  certain offset from the object location
• system classes need to be accessed remotely, but
  they are unmodifiable
• because other system classes access them directly

18
Solution

• System classes are accessed through special
  proxies, but access each other directly

Site 1
Site 2
p
alias2
alias1
19

• What if a system object is passed from system
  code to user code and vice-versa?
• here is an example with both cases q has to
  become q or the code of class R wont work
• System proxies are responsible for both
  translations (wrapping/unwrapping)

r.foo(q)
q
r
q
R
20
Profiling for Performance
http//j-orchestra.org
21
Profiling

• We interpose our profiling code in the Java VM
  method calling mechanism
• every time a method is called, we determine the
  amount of state reachable from the arguments
• this determines the data coupling between two
  classes
• Profiling is a good way to discover application
  behavior without an intrusive runtime

22
Static Analysis
http//j-orchestra.org
23
Static Analysis

• We analyze the application at several levels
• basic analysis (call-graph, inheritance
  hierarchy)
• what system classes are used (recursively)
• to see what we need to rewrite and how, where to
  put them on a network (depending on which class
  uses them)
• what application classes are subclasses of system
  classes
• these will be treated as system classes
• advanced analysis future work (mostly)
• how does a method use its arguments
  (aliased/modified)? What data need to be
  serialized?

24
Concluding
http//j-orchestra.org

• (why do you call it J-Orchestra?)

25
Related Work

• Auto partitioning systems Addistant, Pangaea,
  Coign
• very limited
• Distributed programming infrastructure
  JavaParty, Doorastha
• not automatic
• DSM systems
• but these change the runtime

26
Summary

• J-Orchestra is the first fully general
  auto-partitioning system
• large, complex bytecode rewriting infrastructure,
  several conceptual problems solved for the first
  time
• Many other interesting aspects of the system are
  performance related
• dynamic profiling, static analysis