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

1. A Bytecode Translator for Distributed Execution of “Legacy” Java Software Michiaki Tatsubori University of Tsukuba, Japan 271th PPT, Ohokayama

2. A Bytecode Translator for Distributed Execution of “Legacy” Java Software Michiaki Tatsubori University of Tsukuba, Japan 271th PPT, Ohokayama

3. Developmentof Distributed Java Software • An example scenario • “Wehave 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 271th PPT, Ohokayama

4. Two Approaches • Use X Window • No need to edit a program • Rewrite a program by hand • Using Java RMI or CORBA 271th PPT, Ohokayama

5. X Window • Distribution by the Xliblibrary • Bad response time if GUI is complex • High communication overhead “A mouse moved” “A mouse-button pushed” Xlib “A mouse-button released” UserProgram “Draw a line” 271th PPT, Ohokayama

6. Rewrite a Program by Hand • Good response time • The programmer can tune the code. • Low communication overheads. Higher-level commands ORB Library A click in a window UserProgram UserProgram Show an internal-window 271th PPT, Ohokayama

7. Automation vs. Efficiency • X Window • Fully automated, but • Slow • By hand • Many man-hours, though • Fast Xlib UserProgram GUIModule UserProgram 271th PPT, Ohokayama

8. Automation vs. Efficiency • X Window • Decomposition atthe library layer • For better performance,complex decomposition isnecessary. Xlib UserProgram GUIModule UserProgram 271th PPT, Ohokayama

9. 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. Policy file UserProgram GUIModule 271th PPT, Ohokayama

10. 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 271th PPT, Ohokayama

11. Decomposition is Not Easy… • A simple proxy-master implementation NEVER works. • Proxy-master – a typical implementation technique for remote references MethodInvocation Proxy Master Network Communications 271th PPT, Ohokayama

12. class WidgetProxy implements Widget { … } interface Widget { … } JavaRMI’s Way Doesn’t Work • To be remotely accessible, • We must translate … If WidgetImpl is a system class,we cannot modify the class declaration! The JVM prohibits it. class WidgetImpl { … } implements Widget { 271th PPT, Ohokayama

13. 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” 271th PPT, Ohokayama

14. 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 techniquesdo not modify an original class, so they can be used for system classes. 271th PPT, Ohokayama

15. Distributed Swing Application • A policy file <policy> <importproxy="rename" from="display"> subclass@java.awt.-　subclass@javax.swing.-　.. </import> <importproxy="rename" from="application"> exactsubclass@java.io.[InputStream|OutputStream|..] exactsubclass@javax.swing.filechooser.* </import> <importproxy="subclass"> subclass@java.util.[AbstractCollection|..] </import> <importproxy="writeBackCopy"> array@- </import> <importproxy="replace" from="application"> user@- </import> <importproxy="copy"> - </import> </policy> 271th PPT, Ohokayama

16. Widget Widget show() show() .. Show .. .. Send .. “Replace” Approach(e.g. user classes) • Replaces the master class declaration with a proxy version • When the target class is modifiable Only one version exists on a single JVM. Widget w = new Widget(); w.show(); Make it distributed Replace all 271th PPT, Ohokayama

17. Widget WidgetProxy show() show() .. Show .. .. Send .. “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. Caller-side Class declaration Widget w = new Widget(); w.show(); WidgetProxy w = new WidgetProxy(); w.show(); 271th PPT, Ohokayama

18. Widget WidgetProxy show() show() .. Show .. .. Send .. Local reference Remote reference “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. Caller-side Class declaration Widget w = new Widget(); w.show(); 271th PPT, Ohokayama

19. “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); 271th PPT, Ohokayama

20. Experiment: Response time • “Click” to “Pop-up a Window” • Application Host • Sparc 440MHz • GUI Host • PentiumII 500MHz • Network • 10Base-T Half • 100Base-TX Full 271th PPT, Ohokayama

21. Experiment: Response time • “Click” to “Pop-up a Window” • Application Host • Sparc 440MHz • GUI Host • PentiumII 500MHz • Network • 10Base-T Half • 100Base-TX Full 271th PPT, Ohokayama

22. IBM’s awt-compatible library for remote GUI Results of Experiments • Addistant showed good results. • Response Time (sec.) 10base-t / 100base-tx • Transferred data size (kb) 271th PPT, Ohokayama

23. 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 271th PPT, Ohokayama

24. PTTここだけの話- Caving into Addistant • 分散透過なシステムが気をつけなければならないこと • Global references • Field referencing • Callback thread context • Locking • Reference assignment • Exception handling • Garbage collection 271th PPT, Ohokayama

25. 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) .. 271th PPT, Ohokayama

26. Main Dish- Distributed Callback • コールバックされた synchronized メソッドは、ナイーブな実装ではデットロックを起こす。 pushed() Button ButtonListener MethodInvocation handlePush() getState() 271th PPT, Ohokayama

27. Dessert- Locking, DGC, Fault Tolerance • Bare lock synchronized 文（synchronized メソッドはOK） • Remote thread communication • wait() と notify() • Distributed cyclic garbage Collection • Tolerance for network communication failure 271th PPT, Ohokayama

28. 早く飲みにいきましょう 271th PPT, Ohokayama

29. Automating Development of Distributed Ver. of “Legacy” Soft • Less Developing Costs by Automation • Reusing “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]、… 271th PPT, Ohokayama

30. 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” 271th PPT, Ohokayama