A Bytecode Translator for Distributed Execution of “ Legacy ” Java Software

July 19, 2001 271th PPT, Ohokayama 1

A Bytecode Translator for Distributed Execution of “Legacy” Java Software

Michiaki TatsuboriUniversity of Tsukuba, Japan


A Bytecode Translator for Distributed Execution of “Legacy” Java Software

Michiaki Tatsubori

University of Tsukuba, Japan


Developmentof Distributed Java Software

An example scenario “We have already got nice software.” “But we want to display GUI of the

software on a remote host.” Run GUI components on a remote host,

and run others on a local host


Two Approaches

Use X Window No need to edit a program

Rewrite a program by hand Using Java RMI or CORBA


X Window

Distribution by the Xlib library Bad response time if GUI is complex

High communication overhead

“Draw a line”

“A mouse moved”

“A mouse-button pushed”

“A mouse-button released”

UserProgram

Xlib


Rewrite a Program by Hand

Good response time The programmer can tune the code. Low communication overheads.

UserProgram

Show an internal-window

A click in a window

ORBLibrary

UserProgram

Higher-level commands


Automation vs. Efficiency

X Window Fully automated, but Slow

By hand Many man-hours, though Fast

UserProgram

Xlib

UserProgram

GUI Module


Automation vs. Efficiency

X Window Decomposition at

the library layer

For better performance,complex decomposition isnecessary.

UserProgram

Xlib

UserProgram

GUI Module


Addistant – Our Solution

A Java program translator Translating a non-distributed program

to a distributed one Decomposing at anywhere

The users can specify the decomposition in a policy file.

UserProgram

GUI Module

Policy file


Addistant is a Practical Tool!

Bytecode translation by a class-loader Using Javassist[Chiba00]. No source code, no custom JVM.

Addistant can process real applications. It can migrate Swing components to a

remote host.Standard

library for rich GUI


Decomposition is Not Easy…

A simple proxy-master implementation NEVER works. Proxy-master – a typical

implementation technique for remote references

MasterProxyMethodInvocation

Network Communications


JavaRMI’s Way Doesn’t Work

To be remotely accessible, We must translate …

class WidgetImpl { …}

implements Widget {

interface Widget { …}

class WidgetProxy implements Widget { …}

If WidgetImpl is a system class,we cannot modify the class declaration!The JVM prohibits it.

If WidgetImpl is a system class,we cannot modify the class declaration!The JVM prohibits it.


System Classes

For implementing remote references, different way for a different class is used.Scopes of the required code modification are

different in each implementation Choosing implementation method avoiding

any modification of system classes “ 長いものには巻かれましょう”

Declarative specification in a policy file “Replace”, “Rename”, “Subclass”, “Copy”


In a Policy File of Addistant

Users choose one of four implementation techniques for each class. Those techniques modify code in

different ways. But they have different limitations in use.

Some techniques do not modify an original class, so they can be used for system classes.


Distributed Swing Application

A policy file<policy> <import proxy="rename" from="display"> [email protected] 　 [email protected] 　 .. </import> <import proxy="rename" from="application"> [email protected].[InputStream|OutputStream|..] [email protected].* </import> <import proxy="subclass"> [email protected].[AbstractCollection|..] </import> <import proxy="writeBackCopy"> array@- </import> <import proxy="replace" from="application"> user@- </import> <import proxy="copy"> - </import></policy>


“Replace” Approach(e.g. user classes)

Replaces the master class declaration with a proxy version When the target class is modifiableOnly one version exists on a single JVM.

Widget w = new Widget();w.show();

Widgetshow()

Make it distributed

Widgetshow()

.. Show ..

.. Send ..

Replace all


“Rename” technique(e.g. for java.awt.Window)

It does not modify the original class. But local and remote references

cannot coexist on the same host.


Widgetshow()

.. Show ..

Caller-side Class declaration

WidgetProxyshow()

.. Send ..

WidgetProxy w = new WidgetProxy();w.show();


“Subclass” technique(e.g. for java.util.Vector)

Local and remote references can coexist on the same host.

But the original class must not be final. If final, it must be modifiable.


Widgetshow()

.. Show ..

Caller-side Class declaration

WidgetProxyshow()

.. Send ..

Local referenceRemote reference


“Copy” Approach(e.g. java.lang.String)

Does not create any proxy class, but transfers serialized objects to remote host at RMI Shallow copy

A Variation – “Write-back Copy” Approach For arrays

byte[] buf = …;istream.read(buf);


Experiment: Response time

“Click” to “Pop-up a Window” Application Host

Sparc 440MHz GUI Host

PentiumII 500MHz Network

10Base-T Half 100Base-TX Full


Experiment: Response time

“Click” to “Pop-up a Window” Application Host

Sparc 440MHz GUI Host

PentiumII 500MHz Network

10Base-T Half 100Base-TX Full


Results of Experiments

Addistant showed good results. Response Time (sec.) 10base-t /

100base-tx

Transferred data size (kb)

(±0.1 sec.) X Window Rawt Addistant

1st pop-up 5.6 / 1.6 3.2 / 2.6 2.0 / 2.0

2nd pop-up 5.6 / 1.4 0.0 / 0.0 0.0 / 0.0

X Window Rawt Addistant

1st pop-up 3493.57 116.20 81.88

2nd pop-up 3438.96 10.95 0.06

IBM’s awt-compatiblelibrary for remote GUI


Concluding Remarks

Addistant – an adapter of “legacy” Java programs for their distributed execution on multiple hosts A translator (automation) approach for

complex decomposition of a program A practical technology which can handle

Swing

Other Contribution A case-study of the usefulness of Javassist


PTT ここだけの話- Caving into Addistant

分散透過なシステムが気をつけなければならないこと Global references Field referencing Callback thread context Locking Reference assignment Exception handling Garbage collection


Appetizer- Field Referencing

Proxy-Master では、フィールドアクセスは扱えないが、フィールドアクセスの対象となって

いるオブジェクトの実際の型は静的に決まっているMyWindowB winb = …

.. win.id ..MyWindowA wina = winb; .. win.id ..

MyWindowB winb = … .. MyWindowBProxy._id(win) ..MyWindowA wina = winb; .. MyWindowAProxy._id(win) ..


Main Dish- Distributed Callback

コールバックされた synchronized メソッドは、ナイーブな実装ではデットロックを起こす。

MethodInvocation

pushed()

getState()

ButtonButtonListener

handlePush()


Dessert- Locking, DGC, Fault Tolerance

Bare locksynchronized 文（ synchronized メソッド

は OK ）

Remote thread communication wait() と notify()

Distributed cyclic garbage CollectionTolerance for network communication failure


早く飲みにいきましょう


Automating Development of Distributed Ver. of “Legacy” Soft

Less Developing Costs by AutomationReusing “Legacy”, Existing, Software

Ordinary Environments (Auto Remote GUI) X Window System 、 VNC 、 Rawt[IBM Haifa

98]

Ordinary Tools for (Semi-Auto) Distribution JavaRMI, ObjectSpace, Corba-compliant ORB… ”remotenew”[Nagaratnam 96] ,

JavaParty[Philippen 99] …、


Distributed Execution of Software

For example,Separating GUI from application logic

Reduces administration costs, and Makes use of ubiquitous client-machines

“Zero Administration” “Thin Client”

Documents

A Bytecode Translator for Distributed Execution of “ Legacy ” Java Software