1 / 25

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

A Bytecode Translator for Distributed Execution of “ Legacy ” Java Software. Michiaki Tatsubori * , Toshiyuki Sasaki * , Shigeru Chiba ** , and Kozo Itano * * University of Tsukuba, Japan ** Tokyo Institute of Technology, Japan. Development of Distributed Java Software. An example scenario

winter
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Bytecode Translator for Distributed Execution of “Legacy” Java Software Michiaki Tatsubori*, Toshiyuki Sasaki*, Shigeru Chiba**, and Kozo Itano* * University of Tsukuba, Japan ** Tokyo Institute of Technology, Japan ECOOP 2001, Budapest, Hungary

  2. 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 ECOOP 2001, Budapest, Hungary

  3. Two Approaches • Use X Window • No need to edit a program • Rewrite a program by hand • Using Java RMI or CORBA ECOOP 2001, Budapest, Hungary

  4. 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” ECOOP 2001, Budapest, Hungary

  5. 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 ECOOP 2001, Budapest, Hungary

  6. Automation vs. Efficiency • X Window • Fully automated, but • Slow • By hand • Many man-hours, though • Fast Xlib UserProgram GUIModule UserProgram ECOOP 2001, Budapest, Hungary

  7. Automation vs. Efficiency • X Window • Decomposition atthe library layer • For better performance,complex decomposition isnecessary. Xlib UserProgram GUIModule UserProgram ECOOP 2001, Budapest, Hungary

  8. Addistant– Our Solution • A Java program translator • Translating a non-distributed program to a distributed one • Decomposing at anywhere • The user can specify the decomposition with a policy file. Policy file UserProgram GUIModule ECOOP 2001, Budapest, Hungary

  9. 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 ECOOP 2001, Budapest, Hungary

  10. 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 ECOOP 2001, Budapest, Hungary

  11. 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 { ECOOP 2001, Budapest, Hungary

  12. 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. ECOOP 2001, Budapest, Hungary

  13. 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> ECOOP 2001, Budapest, Hungary

  14. 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(); ECOOP 2001, Budapest, Hungary

  15. 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(); ECOOP 2001, Budapest, Hungary

  16. Experiment: Response time • “Click” to “Pop-up a Window” • Application Host • Sparc 440MHz • GUI Host • PentiumII 500MHz • Network • 10Base-T Half • 100Base-TX Full ECOOP 2001, Budapest, Hungary

  17. Experiment: Response time • “Click” to “Pop-up a Window” • Application Host • Sparc 440MHz • GUI Host • PentiumII 500MHz • Network • 10Base-T Half • 100Base-TX Full ECOOP 2001, Budapest, Hungary

  18. 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) ECOOP 2001, Budapest, Hungary

  19. 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 handles Swing • Other Contribution • A case-study of the usefulness of Javassist[Chiba00] ECOOP 2001, Budapest, Hungary

  20. Question or Suggestion? ECOOP 2001, Budapest, Hungary

  21. 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 • “It’s no use kicking against bricks” • Declarative specification in a policy file • “Replace”, “Rename”, “Subclass”, “Copy” ECOOP 2001, Budapest, Hungary

  22. 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 ECOOP 2001, Budapest, Hungary

  23. “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); ECOOP 2001, Budapest, Hungary

  24. 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]、… ECOOP 2001, Budapest, Hungary

  25. 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” ECOOP 2001, Budapest, Hungary

More Related