Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Mobile J: system support for dynamic application partitioning in the mobile environment Burian, Geoffrey Lloyd 1998

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1998-0369.pdf [ 3.84MB ]
Metadata
JSON: 831-1.0051662.json
JSON-LD: 831-1.0051662-ld.json
RDF/XML (Pretty): 831-1.0051662-rdf.xml
RDF/JSON: 831-1.0051662-rdf.json
Turtle: 831-1.0051662-turtle.txt
N-Triples: 831-1.0051662-rdf-ntriples.txt
Original Record: 831-1.0051662-source.json
Full Text
831-1.0051662-fulltext.txt
Citation
831-1.0051662.ris

Full Text

Mobile J: System Support for Dynamic Application Partitioning in the Mobile Environment by Geoffrey L l o y d Bur i an B . S c . (Hons), The Univers i ty of Br i t i sh C o l u m b i a A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F Maste r o f Science in T H E F A C U L T Y O F G R A D U A T E S T U D I E S (Department of Compute r Science) we accept this thesis as conforming to the required standard The University of British Columbia October 1998 © Geoffrey L l o y d Bur i an , 1998 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of 0<J)nnpxdjttr ^Oi&^c^e The University of British Columbia Vancouver, Canada Date DE-6 (2/88) Abstract W i t h the increasing proliferation of mobile computing devices comes the need for operating system software which supports applications running in the mobile en-vironment. The computational environment of a mobile computer is typical ly more constrained than that of a stat ionary computer, having a less powerful C P U , less available memory, and being connected v ia a network wi th less available bandwidth and higher latency. Various software systems have been developed which at tempt to compensate for these l imitat ions; these may be characterised in terms of how much they hide the mobile environment from applications (mobile-transparency) and the degree to which they can dynamical ly locate application functions between the mo-bile machine and a stat ionary server in order to adapt to changes in the environment. The M o b i l e J system is one which supports mobile-transparent, dynamical ly par t i -tioned applications for use in the mobile environment. B y instrumenting Java class files (object code) and replacing all type references wi th those of proxy classes, the M o b i l e J system provides the basis for runtime control over placement of objects without requiring application programmers to change source code. M o b i l e J pro-vides a mechanism to be used in the investigation of object placement policies for use in applications running in the mobile comput ing environment. i i Contents Abstract ii Contents iii List of Tables vii List of Figures viii Acknowledgements x 1 Introduction 1 1.1 Mobi l e C o m p u t i n g Characterist ics 1 1.2 System Support For Mobi le Appl ica t ions 3 1.2.1 Mob i l e Transparency vs. Mob i l e Awareness 3 1.2.2 Appl ica t ion Par t i t ion ing : 5 1.2.3 A Taxonomy of Systems 8 1.3 Mot iva t ion and Purpose 10 2 MobileJ Architecture and Overview 13 2.1 General Archi tecture and Overview 13 2.2 Stat ic D a t a and M e t h o d Design 15 i i i 2.3 Introduction to Java Concepts 16 3 MobileJ Runtime 21 3.1 Management Layer 21 3.1.1 Runt ime Parameters 21 3.1.2 Object Placement Pol icy 22 3.2 Dis t r ibu t ion Layer 23 3.2.1 Object Creat ion 23 3.2.2 M e t h o d Invocation 24 3.2.3 Object M o b i l i t y 25 3.3 Nat ive L ib ra ry 25 4 Class File Instrumentation Design and Implementation 27 4.1 Introduction 27 4.1.1 Chapter Overview 29 4.2 Class Level Changes . . . . . . 30 4.2.1 Class Names 30 4.2.2 Interfaces 30 4.3 A r r a y s . 31 4.3.1 Design 32 4.3.2 Creat ion 35 4.3.3 Access 40 4.4 M e t h o d Invocation and Return 42 4.4.1 M e t h o d Headers 42 4.4.2 Invocation and Re turn 44 4.5 Object Creat ion and Init ial ization 50 iv 4.6 F ie ld Access 51 4.6.1 F ie ld Signatures 51 4.6.2 Accessor Methods 51 4.6.3 Static Fields 52 4.6.4 Instance Fields 56 4.7 Miscellaneous Changes and Except ional Cases 58 4.7.1 Except ion Classes 58 4.7.2 Strings 59 4.7.3 Type Checking Instructions 63 4.7.4 j a v a . l a n g . C l a s s and Reflection 63 4.7.5 j a v a . l a n g . C h a r a c t e r Class Initializer 64 4.7.6 j a v a . l a n g . R u n t i m e l o a d L i b r a r y M e t h o d 65 4.8 Crea t ing Proxy Classes . . 66 4.9 Implementing Bytecode Instrumentation 67 4.9.1 Main ta in ing F l o w Con t ro l 67 4.9.2 Debugging Support 69 4.10 Summary 70 5 Related Research 71 5.1 J V M Class Instrumentation Tools 71 5.1.1 Bytecode Instrumenting Too l ( B I T ) 71 5.1.2 Java Object Instrumentation Environment ( JOIE) 72 5.1.3 Binary Component Adap ta t ion 72 5.2 Systems Support ing Mob i l e Appl ica t ions 73 5.2.1 Stat ical ly Par t i t ioned Systems 73 5.2.2 Dynamica l ly Par t i t ioned Systems 76 v 6 Conclusions 81 6.1 Summary 81 6.2 Future Work 82 6.2.1 Por t ing A W T Native Methods 82 6.2.2 M o r e Efficient Dis t r ibu t ion Layer 83 6.2.3 D y n a m i c Moni to r ing and Object Placement Pol icy Modules 83 6.2.4 Study of Appl ica t ions and Object Placement Policies . . . . 84 6.3 F i n a l Conclusions 84 Bibliography 85 vi i i List of Tables 1.1 Resource Constraints Influencing an Appl i ca t ion Par t i t ion ing Pol icy 8 1.2 A Taxonomy of Systems Support ing Mob i l e Appl ica t ions 9 2.1 Java T y p e Descriptors 18 4.1 Java A r r a y Access Instructions and Thei r Corresponding A r r a y W r a p p e r Methods 41 vi i List of Figures 1.1 Possible Appl ica t ion Par t i t ion Points 6 2.1 M o b i l e J System Archi tecture 14 2.2 Stat ic D a t a Design 16 4.1 A r r a y Wrapper Class Hierarchy 34 4.2 D a t a Structure and Element Types of a Wrapped Three Dimensional A r r a y of Integers 36 4.3 Instructions Replacing n e w a r r a y . 37 4.4 Instructions Replacing a n e w a r r a y 38 4.5 Instructions Replacing m u l t i a n e w a r r a y 39 4.6 Runt ime Check For " t h i s " A s a Parameter: < s t a c k B i t F i e l d > and <numWords> are integers determined by the Instrument utili ty. . . . 46 4.7 Runt ime Check For " t h i s " A s a M e t h o d Invocation Target 47 4.8 Bytecode Inserted After an Invocation of c l o n e 49 4.9 Bytecode Instrumentation of Constructor Invocation 50 4.10 Static, and Non-Stat ic F ie ld Accessor M e t h o d Names 52 4.11 Bytecode Replacing an Ini t ial izing p u t s t a t i c O f Object Fields . . . 53 4.12 Bytecode Replacing a Non-Ini t ia l iz ing p u t s t a t i c O f Object Fields . 54 vi i i 4.13 Bytecode Replacing a Non-Initializing puts ta t i c Of Primitive Fields 55 4.14 Bytecode Replacing a ge t s ta t i c Of Primitive Fields 56 4.15 Runtime Check For "this" As a Field Access Target 57 4.16 Class Hierarchy For Instrumented Exception Classes 59 4.17 f orStr ing Method Signature and Bytecode 61 4.18 toRealStr ing Method Signature and Bytecode 62 ix Acknowledgements Though my name appears as the author of this work, many have supported me through the past two years as I completed this degree and thesis. . Thanks are due to Professor M i k e Feeley for helping me learn and for en-couraging, understanding, and support ing me during part icularly stressful times. Thanks also to my supervisor, Professor N o r m Hutchinson for his support , direc-t ion, and feedback on my ideas during the formulation of this thesis. I'd also like to thank my parents, both those who have been there since the beginning, and those more recently acquired. Thank-you for your love and support (financial and otherwise!), especially over the past two years. B u t most of all I would like to thank my wife, A m y - L y n n . Thanks for your love, patience, and encouragement as I finished my schooling. Thanks for sharing this adventure wi th me! G E O F F R E Y L L O Y D B U R I A N Vancouver, British Columbia October 1998 x Chapter 1 Introduction 1.1 Mobile Computing Characteristics W i t h i n contemporary distributed computing, the term mobile computing has come to refer to environments where computat ional devices have the abili ty to function at arbitrary, as opposed to fixed, physical locations. Whereas t radi t ional distr ibuted computing models have assumed that machines typical ly remained at a fixed location for long periods of t ime, mobile computing assumes they have the abil i ty to change their physical and possibly their logical (or network) locat ion. A t least three trends have contributed to the emergence of mobile comput ing . F i r s t , the increasing proliferation of computat ional devices has meant that more t radi t ional ly mobile, yet non-computerized tools, are being made available. For example, personal appointment books, once handled solely by pencil and paper, are now often kept entirely using a digi tal computer. Second, the shrinking size of relatively powerful computat ional devices is making them much easier to move around. W h a t was once too large to conveniently carry now fits easily in the palm of 1 a user's hand. T h i r d , wireless networks and associated communications protocols are enabling applications requiring a network connection to run on computers without requiring them to be physically connected by a wire. Whi l e we have solved some of the technical challenges involved in creating computat ional devices small enough to move around yet powerful enough to be useful, there remain many issues inherent to mobile computing which must be in-vestigated further [Sat96]. F i r s t , mobile computing devices wi l l always have fewer resources (for funds spent) compared to stat ionary devices. They wi l l have less mem-ory, less powerful C P U s , and likely be connected by networks wi th lower available bandwidth and higher latency than stat ionary devices. Second, the computational environment, meaning pr imari ly the C P U power, available memory, and network connection quality, wi l l usually be highly variable. A s we move from environments where users control few stationary computers (or, often, a single computer) , to one in which users access many different computat ional devices from many locations, more variabil i ty is inevitable. A s people are enabled to access their home environment from a variety of physical locations, so to wil l their computat ional environment vary. For example, even when using the same computat ional device, the connec-tion to a mobile host can vary between being completely disconnected, and being connected v i a a relatively reliable wired L A N . Wireless networks have inherent prob-lems wi th performance and reliabili ty because their physical transport medium, ra-dio waves, can and does interact wi th its environment. A s a mobile computer moves while accessing a wireless network, its environment changes, and thus the quali ty of its network connection changes as well . Because of the usually lower perfor-mance of a wireless network, users of mobile computers should be given the option 2 of being connected by a high-performance wired link; this also creates variabil i ty in connection quality. A number of other differences exist between the mobile comput ing environ-ment and the stat ionary environment, however, the two mentioned above wi l l be the focus of this thesis. The following two sections discuss different approaches to these challenges, and introduces the particular technique described in the remainder of this thesis. 1.2 System Support For Mobile Applications Given the unique characteristics of the mobile comput ing environment mentioned above, many applications designed for use in a stat ionary environment wi l l not perform well. Thus various application design frameworks and system software services have been developed for creating or adapting applications for use in the mobile computing environment. 1.2.1 M o b i l e Transparency vs. M o b i l e Awareness A pr imary concern in the design of any software system support ing mobile applica-tions, is the degree to which it is transparent to the application [Sat96]. A t one end of the spectrum are "ad-hoc" solutions, whereby individual applications implement the services necessary for them to function well on a mobile computer. These appli-cations are completely mobile-aware because the software which supports operation on a mobile host is integrated wi th the software which performs normal application logic. Th i s solution has the advantage of being tailored exactly to a part icular ap-plication's needs, but has a major disadvantage in that code support ing mobil i ty is duplicated for each applicat ion. Not only is more memory (and possibly other 3 resources) required to run multiple applications on the mobile computer, but much more development t ime is needed by the application designer and implementer; this effect is mult ipl ied by the number of mobile applications created. Th i s problem is merely a part icular case of the argument for the existence of operating system services in the more general case. A t the other end of the spectrum are systems which allow applications to run without modification on a mobile computer. Usual ly this is done by redesigning system software such that it takes the mobile comput ing environment into consid-eration. The application is not, for the most .part , aware that it is running on a mobile host, and is designated mobile-transparent. Th i s solution has the advantage of allowing many applications not designed for mobile comput ing to run on a mo-bile computer, and also does not require major application software reengineering efforts; application engineers can continue to build applications as if they were cre-ating software for stat ionary computers. The possible disadvantage of this approach is that it may not be possible to implement system software in such a way as to foresee and compensate for the impact of mobile comput ing for al l applications. The way the mobile comput ing environment impacts one part icular application may be quite different than for another applicat ion. In the middle of this continuum lie strategies which provide system software services for aiding applications to function in the mobile comput ing environment. Th is strategy attempts to merge the advantages of both ends of the spectrum to achieve an ideal solution. Therefore, current applications would require a certain amount of redesign in order to work on mobile hosts, but the application designer would have control over what services were used by the application and under which circumstances. M o s t of the software support ing mobi l i ty would be shared by mobile 4 applications, but they would be able to use it in ways specific to their needs. Th i s strategy creates applications which are mobile-transparent to the extent that the system software hides the mobile comput ing environment. The difficulty inherent to this approach is the same as for any implementer of system software, that being how to design services such that the system is capable of support ing the needs of all applications, while also not being too complex or cumbersome to use and maintain . 1.2.2 Application Partitioning M o s t software that enables applications to be built or modified for use in the mo-bile comput ing environment can be described in terms of application partitioning [Wat95]. A parti t ioned application is one in which the user interface and possibly some part of the general application logic executes on a mobile host, while another part executes on a more powerful, stat ionary host. The two parts are typical ly connected by a wireless network l ink. The part i t ion is created in such a way as to minimize reliance on the scarce resources of the mobile host and the low bandwidth and high latency wireless network connection. The ideal part i t ion is one in which large da ta sets and functions requiring high computat ional power are located on the relatively large and powerful s tat ionary host, while communicat ion between the hosts is optimized for the poor performing wireless network. For example, the Sci-encePad system described in [ D W J + 9 6 ] at tempts to provide a "ubiquitous problem solving environment" for scientists by par t i t ioning applications between a small , mo-bile host used to display the user-interface and more powerful hosts used to perform computat ion. 5 user interface GUI pixels UFS, NFS X Windows protocol dynamic partitioning sockets filesystem interface OS I/O interfaces network interface Figure 1.1: Possible Appl ica t ion Par t i t ion Points Partitioning Point A n application can be parti t ioned at many different points as i l lustrated in F i g -ure 1.1. A n application can be parti t ioned at some layer of its user-interface code, as described in [ R S F W H 9 8 ] . However, depending on the point at which the part i-t ion is implemented, this scheme may require many interactions between the mobile and stat ionary hosts as the user controls the application, part icularly if a modern, graphical user interface is used. Therefore, performance over a high latency wireless' network would not be op t imal . A l s o , if the part i t ion involves sending pixel images of the user's display, the low bandwidth restrictions of a wireless network may make adequate performance difficult to achieve, as noted in [ K D F + 9 3 ] . Alternat ively, an application can be partit ioned at the filesystem or network access level. However, this assumes that the mobile host is powerful enough and has a large enough memory to accommodate the execution of most of the applicat ion. Th i s scheme may be appropriate for a relatively powerful mobile host which needs access to a large data set, but may not be appropriate for use on smaller, less powerful mobile hosts. 6 Static vs. Dynamic Partitioning Appl ica t ion part i t ioning can be implemented in either a static or dynamic fashion. A static part i t ion is one in which the part i t ion point stays fixed during application execution and over consecutive executions of the application. A dynamic part i t ion is one in which the part i t ion point can change between consecutive executions of the applicat ion, or even during the execution of the application. A static part i t ioning scheme is very similar to the t radi t ional client-server model of network applications, though the placement of functionality may be differ-ent to compensate for the differences between a powerful, well-connected client and a small , poorly connected mobile host [Sat96]. Stat ic part i t ioning usually implies some degree of mobile awareness on the part of the application and thus of the application developer. It may also assume the application wi l l always execute on a mobile host of a particular computat ional performance, memory size, and connected by a wireless network. A dynamic part i t ioning scheme, on the other hand, allows for more flexibili ty than a static par t i t ion. A s noted in Section 1.1, the mobile comput ing environment is characterised by high variabil i ty in C P U power, available memory, and network connection qual i ty-var iabi l i ty that is likely to increase in the future as users are enabled to become less tied to a physical location in order to access their home environment. A s the computat ional environment changes, it may be desirable to change an application's part i t ion point: one part i t ioning configuration may not be suitable for all environmental configurations. 7 Resource Cond i t ion Po l i cy network high latency migrate objects wi th many interactions to the same host low bandwidth migrate objects wi th high bandwidth interac-tion to the same host mobile C P U high load migrate/create computat ional ly expensive ob-jects t o / a t stationary host migrate/create threads to /a t stationary host mobile memory memory full migrate/create large objects to /a t s tat ionary host Table 1.1: Resource Constraints Influencing an Appl ica t ion Par t i t ion ing Pol icy Partitioning Policy In designing a parti t ioned applicat ion, or system support for part i t ioning, decisions must be made on an appropriate distr ibution of application data and function exe-cution between the mobile and fixed hosts. Table 1.1 displays the factors which can influence these decisions. (Table 1.1 expresses application components in terms of object instances, where object location implies both da ta and computat ion location.) It should be noted that in a completely mobile environment, the conditions of all resources can change both between executions of an application, and during its execution. A s a particular resource becomes more constrained, so too does its relative importance to an application part i t ioning policy. A l so , for resources which are "equally" constrained (for some definition of "equal"), a part i t ioning policy must weigh the relative influence of each resource condit ion when choosing where to place an object. 1.2.3 A Taxonomy of Systems Table 1.2 shows a taxonomy of systems wi th some degree of support for mobile applications. The systems are categorized according to the s ta t ic /dynamic nature of 8 Static Pa r t i t i on D y n a m i c P a r t i t i o n M o b i l e - A w a r e • Odyssey [Nob98, NSN+97 , NPS95] • Well ing 's system [WB98, W B 9 7 ] • Rover [ J T K 9 7 , J K 9 6 , Tau96, JdT+95] • Sumat ra [ARS97, R A S S 9 7 , R A S 9 6 ] • Wi t [Wat95 , Wat94b, Wat94a] Mobile-Transparent • wireless X [KDF+93] [Dan94] • V N C [ R S F W H 9 8 , W R B + 9 7 ] • A M I G O S [ H R A J 9 8 , H R 9 6 , G M 9 5 ] • M A F [HR97] • M o b i l e J • M - M a i l [Lo97, L K 9 6 ] • Coign [HS98b, HS98a , HS97] Table 1.2: A Taxonomy of Systems Support ing Mobi le Appl ica t ions their application part i t ion and the degree to which they hide the mobile environment from applications. Stat ical ly partit ioned systems tend to be implemented at either the network or file system interface, or at some layer of the user-interface/graphical display layer. For example, Odyssey concentrates on mobile file access, while the wireless X and V N C systems focus on re-direction of an application's user-interface to a mobile host. Dynamica l ly part i t ioned systems, for example Rover, Sumatra , W i t , and M o b i l e J , often rely on a software interpreter for dynamical ly moving and loading code and data . These systems are described more fully in Section 5.2, beginning on page 73. 9 1.3 Motivation and Purpose This thesis describes the design and implementation of M o b i l e J , a mobile-transparent system which can be used to create dynamical ly partit ioned applications for exe-cution on the Java V i r t u a l Machine . M o s t other systems for support ing mobile applications are either mobile-aware or use static part i t ioning (or both) , however, dynamical ly part i t ioned, mobile-transparent systems have significant potential ad-vantages over these systems and more research is needed to further characterise and verify their potential . A s discussed above, a disadvantage of mobile-aware systems is the need for application engineers to concentrate on both t radi t ional application design and i m -plementation, as well as issues related to the mobile nature of the applicat ion. Mobile-transparent systems free software engineers from concern about these is-sues, allowing them to continue developing applications for the mobile environment as they* have for the stationary environment. Th is promotes quicker development of new applications for use in the mobile environment, and allows for applications previously developed for the stat ionary environment to be used on a mobile host. The major potential disadvantage of mobile-transparent systems is that the system may not be able to compensate for the mobile environment enough for al l applications to achieve adequate performance. In this case, and especially when the system also allows for dynamic par t i t ioning as does M o b i l e J , mobile-transparent systems st i l l provide a platform for development of application prototypes where various configurations can be rapidly tested. A good understanding of how the application should be opt imally configured for use in the mobile environment can thus be achieved quickly. Whi l e the current version of M o b i l e J does not implement completely auto-10 matic, runtime control of dis t r ibut ion, it does provide the basis for implementation of specific object placement policies. In particular, M o b i l e J can be used as a tool to investigate at least three research questions concerning the part i t ioning of mobile applications. F i r s t , there is a need to determine at what point various types of appli-cations should be parti t ioned for best performance in a mobile environment. W i t h M o b i l e J , there is the possibility of testing many applications built wi thout explicit support for mobil i ty to determine an opt imal object placement configuration. Second, there is a need to investigate to what extent various resource con-straints inherent to the mobile environment should influence part i t ioning policies. For example, moving an object from the mobile host to a stationary host frees mem-ory on the mobile host, but the cost of t ransport ing the object over a low bandwidth wireless network may not make the transfer worthwhile. Given the highly variable nature of the mobile computing environment, there is a need to understand a vari-ety of environmental configurations and how applications should be parti t ioned for each. T h i r d , M o b i l e J can be used to explore the possibility of runtime control over part i t ioning policy. W i t h the addit ion of a resource monitor ing module, M o b i l e J could be used to control all object placement decisions for a running application according to a set of rules. It remains to be determined, however, if the advantages of this strategy wi l l outweigh its possible disadvantages compared to more mobile-aware methods. M o s t systems which support mobile-transparent application part i t ioning do so by changing or adding to operating system or l ibrary code. Do ing so places constraints on where a part i t ion can be made and also on how dynamic the par t i t ion can be. M o s t systems which implement a dynamic par t i t ion, however, also create 11 a mobile-aware system, where application programmers must consider how their application wi l l be affected by the mobile environment. A s an alternative design, instrumenting application executable code, as is done in M o b i l e J , has the advantage of part i t ioning an application at an arbi trary point, under runtime control . A s no source code is changed, using instrumenta-tion also enables a mobile-transparent system to be created; ideally the application programmer need not concern himself wi th the details of application distr ibution between hosts. It is the intent of the Mob i l e J project to create a software infrastruc-ture whereby one can investigate how far the mobile-transparent approach can go in terms of adjusting to the constraints of the mobile environment, and in part i t ioning applications not necessarily designed for the mobile environment. The Java V i r t u a l Machine ( J V M ) class file (object code) format provides an excellent basis for such a project, as wi l l be described in the following section. 12 Chapter 2 Mobi le J Architecture and Overview 2.1 General Architecture and Overview Figure 2.1 (page 14) shows the overall system architecture of the M o b i l e J system. Java class files (object code), as produced by a Java language compiler or assembler, are first processed by the Mob i l e J Instrument tool , creating instrumented bytecode in the form of addit ional class files. The instrumented code, along with the MobileJ Runtime, is executed on a Java V i r t u a l Machine ( J V M ) , wi th the assistance of a native l ibrary. Typical ly , a running M o b i l e J system consists of a single client and a single server which communicate v ia a T C P / I P network connection. It is also possible for the client and server to run on the same J V M , i.e., the client host and server host are the same. The only difference between running M o b i l e J as a client and running M o b i l e J as a server is that when running as a client, the m a i n ( ) method of 13 Application Executable MobileJ Runtime Instrument Tool J Instrumented MobileJ Application Management Layer Native Distribution Layer Java Virtual Machine Library Figure 2 . 1 : Mob i l e J System Archi tecture a specified application is invoked, while when running as a server it is not. When running as the client, the Mob i l e J Runt ime supports execution of a single application; similarly, when running as a server, Mob i l e J supports connection wi th a single client. A l s o , Mob i l e J currently has support for a single server per client application, but it is possible that this could be extended to support multiple servers per client applicat ion. The Mob i l e J Runt ime is responsible for distr ibution of objects created by the instrumented application between the client (mobile) and server (fixed) hosts on the network. In particular, the management layer manages an object placement policy, while the dis tr ibut ion layer is responsible for implementing the policy of the management layer-moving objects between the two hosts. Mob i l e J makes use of proxy objects to maintain location transparency of application objects. Each proxy object is an instance of a proxy class, of which there is one corresponding to each instrumented class used under M o b i l e J 1 . P roxy objects 'Exceptions to this are instrumented versions of java.lang.String, and subclasses of Java. lang.Throwable. No proxy classes are created for these classes. The reasons for these naming exceptions are described in sections 4.7.2 and 4.7.1. M form part of the M o b i l e J Runt ime Dis t r ibu t ion Layer (see Section 3.2, page 23). The Mob i l e J Instrument tool changes class files such that their code manip-ulates proxy objects almost exclusively; nearly all objects created and manipulated by an application running under M o b i l e J are proxy objects. A l l instance method invocations are done through a proxy object which invokes the method on a local object i f the object resides on the local host, or on a remote object, if the object associated wi th the proxy resides on the remote host. Constructors (init ialization methods called at object creation time) of proxy classes create non-proxy (real) objects on either the mobile or fixed host, as determined by the M o b i l e J Runt ime. B o t h the Mob i l e J Instrument tool and Runt ime are wri t ten entirely in Java, wi th the Runt ime requiring support from a native code l ibrary wri t ten in C . The native l ibrary is necessary because of the tight integration between certain classes in the Java standard l ibrary wi th the J V M , and also to implement native methods of the instrumented versions of the standard Java classes. 2.2 Static Data and Method Design A n application running under M o b i l e J executes as if it were executing on a single host. Because there are two Java V M s operating concurrently in a typical config-uration of M o b i l e J , there are two copies of static da ta and two possible locations where static methods may be invoked. To preserve the semantics of a Java application executing on a single host, M o b i l e J identifies the server host as the static host in the M o b i l e J system. Figure 2.2 (page 16) shows the design of M o b i l e J static data . A l l object type static fields created in a static initializer method are created, by default, on the static host. (This placement can be changed according to the Object Placement Policy, as described 15 ® ® Non-Static Host Static Host proxy object static field (non-proxy object) Figure 2.2: Stat ic D a t a Design in Section 3.1.2, page 22.) P r imi t ive type static fields are located, by default, on the static host and cannot be moved. Object type static fields are accessed v ia a local reference to a proxy object, while pr imit ive type static fields are accessed v ia static accessor methods added to a class during instrumentat ion, as described in Section 4.6.3, page 52. Stat ic methods are always executed on the host where the invocation begins because this does not change the semantics of static method invocation for a Java application running on a single host. 2.3 Introduction to Java Concepts This section presents an introduct ion to the Java language, runtime environment, and class file (object code) format. Fur ther sections of this thesis assume knowledge of these concepts. Java [Fla97] is an object-oriented programming language and runtime envi-16 ronment invented by engineers at Sun Microsystems. Java A S C I I text source files are compiled by the j a v a c compiler into class files containing bytecode instructions. The bytecode is interpreted by the Java Virtual Machine ( J V M ) [MD97] , an efficient runtime environment implemented in software atop various hardware and operating system platforms. Because its object code format, class files, can be executed on any machine architecture and operating system to which the J V M has been ported, Java is said to be architecture independent and portable. D a t a in Java programs is either of a pr imit ive type, handled by value, or a reference type. P r imi t ive types include shorts, integers, longs, floats, doubles, characters, bytes, and booleans. Reference types are either arrays or objects which are instances of classes declared in Java source code. A s wi th many object-oriented languages, Java classes exist in an inheritance hierarchy, rooted at the class J a v a . l a n g . O b j e c t . Classes must inherit from only one super-class, but may implement any number of interfaces (see below). Classes are grouped into packages; the full name of a class consists of the package name and the class' simple name. For example, J a v a . l a n g . O b j e c t is in the package J a v a . l a n g and its simple name is O b j e c t . Java classes contain procedures, called methods, and variables, called fields. Java methods may be either constructors, instance methods, or static methods. C o n -structors are invoked (called) to init ial ize a new class instance (object). Instance methods, when invoked, are impl ic i t ly passed a reference to a part icular object by which instance fields may be referenced. Stat ic methods, sometimes referred to as class methods, are not passed a reference to a particular object when invoked. 17 T y p e Desc r ip to r P r i m i t i v e Types byte B char C double D float F int I long J short S boolean Z Reference Types class LXc lass name>; array [<type> Table 2.1: Java Type Descriptors In the class file format, methods are identified by name and type descriptor, or signature. A method type descriptor is of the form: (<parameter types>)<return type> where <parameter types> is a concatenation of the type descriptors of all parameters for the method, and <return type> is the type descriptor of the method's result. Table 2.1 shows the type descriptors of all Java pr imit ive and reference types. Whi le most methods in a Java program are defined wi th bytecode instruc-tions interpreted by the v i r tua l machine, methods may also be declared as na t i ve , in which case they are defined by code compiled to the instruction set of the par-t icular hardware C P U on which the v i r tua l machine is executing. The use of native methods l imits the portabi l i ty of a Java class because a different object code rep-resentation is needed for each machine architecture and operating system on which the code is to run. Java methods may "throw" any number of exceptions. Except ions are objects which inherit from the class java. lang.Throwable. Exceptions propagate from the 18 point they are thrown, up through the method call stack unti l they are trapped by an exception handler for their type, or they reach the top of the stack, at which point the J V M halts execution. Java fields may be either instance fields or static fields. Each object created by a Java program may have a number of associated instance fields allocated wi th i t . These may be of pr imit ive or reference type. Static fields are allocated on a per-class basis and may optionally be init ialized when the class is loaded into the v i r tua l machine v i a a static init ializer method. A Java class may implement any number of interfaces, which are declarations of methods and constant static fields. The names, parameter types, and return type of each method is declared in an interface, and a class which implements the interface must contain implementations of these methods. • * Java source code is compiled into an object code format known as class files. Each class file contains the executable code and structure for one Java class or interface. W i t h i n a class file is a constant pool in which is stored all constant da ta such as class names, method names, and string and numerical constants referred to by various structures and executable code in the remainder of the class file. The large amount of symbolic information retained in a class file facilitates dynamic l inking of code both locally or even over a network. It also makes this executable format easier to instrument compared to more t radi t ional operating system executable formats. The J V M loads class files on demand and interprets method bytecode in -structions. The J V M is a stack-based vi r tual machine; the J V M instruction set contains many instructions for manipulat ing data on the stack, as well as fairly high-level instructions, for example, to invoke a method. Being stack-based also makes instrumentation of bytecode somewhat easier as code can be inserted while 19 retaining the current stack state. Whi l e the bulk of most Java applications consists of bytecode interpreted by the J V M , a Java Nat ive Interface (JNI) [Sun97] also exists to allow l inking of methods compiled to the instruction set of the hardware on which the J V M is executing. 20 Chapter 3 Mobi le J Runtime 3.1 Management Layer The Mob i l e J Management Layer is the portion of the Runt ime which is responsible for application s tar tup and for controll ing any runtime decisions regarding object placement between the two hosts in a Mob i l e J system. T h e Management Layer uses the services of the Dis t r ibu t ion Layer to implement its policies. 3.1.1 R u n t i m e Parameters The Mob i l e J Runt ime system may be invoked wi th a number of parameters which control the configuration and operation of the system: • - p o r t < p o r t numbe r> - T C P port number identifying this Mob i l e J Runt ime instance • - c l i e n t < c l i e n t - a d d r e s s : p o r t > - domain name or IP address and T C P port number of the M o b i l e J client; specified when running as a server 21 • - s e r v e r < s e r v e r - a d d r e s s : p o r t > - domain name or IP address and T C P port number o f the Mob i l e J server; specified when running as a client • - m a i n < m a i n - c l a s s > - name of the proxy class containing the main() method of the application to be run; this is only specified when running in client mode and must be the final M o b i l e J argument on the command line, after which al l application specific arguments must be placed • - t r a c e < t r a c e - f i l e > - name of a file to which all M o b i l e J method call trace output should be directed Thus , specifying a client address starts M o b i l e J in server mode, while speci-fying a server address starts M o b i l e J in client mode. 3.1.2 Object Placement Policy A s discussed in Section 1.3 (page 10), many environmental factors could influence an object placement policy used for application par t i t ioning in a mobile computing environment. M o b i l e J currently supports placement policies based on Object Type only, though other, more sophisticated policies could be added with relative ease, (see Section 6.2, page 82). The M o b i l e J Runt ime has a number of static (Java class) fields which may be referenced by an executing M o b i l e J applicat ion. References to these fields are placed in instrumented code as required. Par t icular uses of these fields are described in Chapter 4, which begins o n page 27. The following static fields are referenced by instrumented application code: The first four fields store the Internet domain name and T C P port number of an instance of the M o b i l e J Runt ime: 22 • S t r i n g STATIC-HOST - host where static field da ta is stored by default • S t r i n g CL IENT_H0ST - host where Mobi l e J runs in client mode • S t r i n g SERVER_HOST - host where Mobi l e J runs in server mode • S t r i n g OTHERJ IOST- same as SERVER J iOST when running in client mode; same as CL IENT_HOST when running in server mode Three fields store boolean values which may be checked in instrumented application code: • b o o l e a n i s S e r v e r H o s t - true if the instance of M o b i l e J is running in server mode • b o o l e a n i s C l i e n t H o s t - true if the instance of M o b i l e J is running in client mode • b o o l e a n i s S t a t i c H o s t - true if the instance of Mob i l e J is the static host 3.2 Distribution Layer The M o b i l e J Dis t r ibu t ion Layer is responsible for implementing location transpar-ent method invocation v i a proxy objects. The general format of proxy classes is described in Section 4.8, page 66. The current implementation of M o b i l e J uses Voy-ager [Obj97] as its Dis t r ibu t ion Layer, but this could be replaced in the future (see Section 6.2.2, page 83). 3.2.1 Object Crea t ion W h e n a new instance of a proxy object is created (by code which has been processed by the Instrument tool) , it must, as part of its ini t ia l izat ion, create an instance of 23 the class for which it is a proxy. The non-proxy instance can be created either on the local machine or on a remote machine, depending on the location passed to the proxy constructor. Wherever the non-proxy object is created, the proxy object maintains a way to reference this object for further method invocations. The proxy object is able to find its corresponding non-proxy object even after being cloned or serialized and sent to a remote machine, as happens when proxies are sent as arguments in method invocations to a remote machine. 3.2.2 M e t h o d Invocation Appl ica t ion code which invokes an instance method or constructor does so using a reference to a local proxy object. The proxy object method must first determine i f its non-proxy object is local or remote. If the object is local , it invokes the appropriate method in the non-proxy object, passing any arguments as supplied by the caller. If the method has a result, it is returned by the proxy method to the application code. If the object is remote, the proxy object serializes all method arguments (using standard Java object serialization [RWW96]) , i f any, and sends them in a method invocation request to the remote Mob i l e J host. Upon receiving an invocation request and its associated arguments, M o b i l e J deserializes all method arguments, finds the non-proxy object for the invocation, and invokes the method, passing all method arguments. Since all object type arguments, including references to arrays, are proxy objects, serialization and deserialization only creates a copy of the proxy objects, not the objects they represent, preserving method invocation semantics for remote calls. W h e n the method returns, a reply, including any result value, is sent back 24 to the original Mob i l e J host. The result value is deserialized and returned to the invoking application code by the proxy method. If the remote method throws an unhandled exception, this is caught by M o -bileJ on the remote side, sent back to the original host, where it is re-thrown to the application code making the method cal l . 3.2.3 Object M o b i l i t y In addit ion to remote object construction and method invocation, the M o b i l e J D i s -t r ibut ion Layer also supports moving an object between hosts once created. A proxy object can be directed to move the instance it represents to a specific M o b i l e J host and port by invoking its moveTo method. The M o b i l e J Runt ime is passed a reference to all proxy objects when created so that an object placement policy module can move objects between hosts as desired. After moving an object, al l proxies which exist for the object must s t i l l be able to find the object. Th is is accomplished in the current implementat ion of M o b i l e J (i.e., in Voyager) by forwarding all method invocations from the previous host to the new host, and returning the new location when sending the invocation result. 3.3 Native Library Though , where possible, the M o b i l e J Runt ime is implemented in Java, a native code l ibrary consisting of compiled C code is also required. This is needed pr imar i ly to supply definitions of native methods in instrumented versions of classes in the standard Java Class Library . T w o native methods which access Java V i r t u a l Machine da ta structures, 25 c h e c k F o r T h i s P a r a m and c h e c k F o r T h i s T a r g e t , are also found in the M o b i l e J N a -tive Library . These methods are described in Section 4.4.2, page 44. 26 Chapter 4 Class File Instrumentation Design and Implementation 4.1 Introduction The M o b i l e J system includes an applicat ion, the Instrument tool , which processes zip (or jar) format files containing Java class files. In converting Java class files for use under M o b i l e J , the pr imary job of the Instrument tool is to change most type (class) references such that they are references to proxy classes. Because Java objects are handled by reference, proxy objects may be passed to and returned from method invocations, even between hosts, wi thout changing the semantics of method invocations. The Instrument tool processes class files in two steps. The first step converts class files for use wi th the Mob i l e J Runt ime (see Chapter 3, beginning on page 21). The second step creates a proxy class based on the instrumented version of the original Java class. 27 B y using proxy classes, object creation and method invocations may be inter-cepted and re-directed to the appropriate host. However, not all accesses to objects are done through method invocations. F i r s t , arrays are objects in Java, but have special J V M instructions which create and manipulate them. For dealing wi th ar-rays, the M o b i l e J Instrument tool creates wrapper classes, through which a l l arrays are accessed, as described in Section 4.3 (page 31). Second, fields are also manipu-lated directly by J V M instructions. The Instrument tool creates accessor methods for fields so that accesses to fields can be intercepted by proxy objects in the same way as method invocations (see Section 4.6, page 51). Because all Java applications depend on the standard Java Class Library , this l ibrary was instrumented to create instrumented classes and proxy classes which correspond to all classes in the library. A l l instrumented classes and proxy classes eventually inherit from j a v a . l a n g . O b j e c t , thus this class is not instrumented. To support an Object T y p e object placement policy (Section 3.1.2, page 22), the Instrument tool accepts a parameter file as input when instrumenting a set of class files which indicates on which host, client or server, particular types of objects should be created. Specifying these parameters at instrumentation t ime means re-instrumenting classes to change these parameters, however, specifying this information stat ically makes for a much more efficient implementat ion. W i t h a static implementat ion, object location names may be specified by referencing one of either CL IENT_HOST or SERVER-HOST variables in the M o b i l e J Runt ime. However, indicat ing object creation location at run t ime would require an extra method cal l and hashtable lookup every t ime an object was created, even for locally created objects. Furthermore, the host a particular type of object is created on, i f it is specified at a l l , is unlikely to change unless the class changes, which would require 28 re-instrumentation anyways. Objects of types not specified in the instrumentation parameter file are al-ways created on the local host, i.e., the host where the thread is running. Thus , by specifying where objects of a part icular type are created, one can specify where most other objects created by objects of this type are created. 4.1.1 Chapter Overview This chapter describes the changes made to class files by the Instrument tool in order to prepare them for execution wi th M o b i l e J . P r imar i l y this involves changing all references to classes into references to proxy classes (Section 4.2). Since arrays are created and manipulated directly by J V M instructions, a method was needed to intercept these operations and allow for location transparent access to arrays, as described in Section 4.3. Section 4.4 describes how method invocation was made location transparent by making most method invocations go through a proxy object. Section 4.5 describes tiow proxy objects are created in instrumented bytecode so that nearly al l objects manipulated by a M o b i l e J application are proxy objects. Because fields are also manipulated directly by J V M instructions, these instructions are generally transformed into method invocations through a proxy object, as described in Section 4.6. Section 4.7 details a number of miscellaneous changes required to allow instrumented class files to run under M o b i l e J . F inal ly , sections 4.8 and 4.9 provide an overview of how proxy classes are created and discussion of two issues pertaining to the implementation of bytecode instrumentat ion, repectively. 29 4.2 Class Level Changes 4.2.1 Class Names The most fundamental change to al l instrumented classes is their change of name. M o b i l e J instrumented classes are given a new name by being placed in a new package which has " u b c . m j . " prepended to the original package name. For example, the instrumented version of the class j a v a . l a n g . S y s t e m becomes u b c . m j . j a v a . l a n g . S y s t e m . Proxy classes are also named by prepending " u b c . m j . " to the original pack-age name, but in addit ion have " V " 1 prepended to the original simple class name. For example, the proxy class corresponding to the original j a v a . l a n g . S y s t e m class is named u b c . m j . j a v a . l a n g . V S y s t e m . M o s t class names referenced in class files are changed to their equivalent proxy class name; exceptions to this rule include j a v a . l a n g . S t r i n g and all Java exception classes, i.e., subclasses of J a v a . l a n g . T h r o w a b l e which are described in sections 4.7.1 (page 58) and 4.7.2 (page 59). A l so , as all instrumented and proxy objects eventually inherit from j a v a . l a n g . O b j e c t , neither a proxy class nor instru-mented class is created for O b j e c t . 4.2.2 Interfaces Because Java interfaces have corresponding class files which are instrumented, the interfaces implemented by a part icular class must have their names changed as well . A class is changed such that it implements instrumented interfaces correspond-ing to its original interfaces. The only exception to this is the marker interface 'The "V" stands for "virtual class", which is the terminology adopted by Voyager for referring to proxy classes. 30 J a v a . l a n g . C l o n e a b l e , which is left as being implemented so that it continues to indicate to the J V M that the class's instances may be cloned. M o s t objects of instrumented classes need to support being moved be-tween machines; this is accomplished by the M o b i l e J Dis t r ibu t ion Layer which, in turn , uses Java object serialization to serialize object da ta for transmis-sion over the network. Therefore, all instrumented classes must implement the J a v a , i o . S e r i a l i z a b l e interface, indicating that they may be serialized. Th i s is ensured by the Instrument tool . 4.3 Arrays A s noted above, M o b i l e J makes use of proxy objects to hide the location of the "real" objects referenced by them. Because objects are handled by reference in Java, the proxy objects can effectively direct method invocations to the appropriate "real" object, whether on the local machine or a remote one-either way, the semantics of Java method invocation are preserved. W i t h the addit ion of accessor methods for object fields, al l object state manipulat ion can be trapped by proxy objects at the method invocation level. Like "normal" objects, Java arrays are also manipulated by reference, how-ever, there are two pr imary differences relevant to M o b i l e J between arrays and normal objects. F i r s t , Java array classes are created dynamically, at run time, by the J V M , and not stored in class files. Thus no array class files exist upon which an instrumented version of the array class or proxy class can be based. Second, there are a number of J V M bytecode instructions which create and operate on arrays; these cannot be "trapped" by proxy objects without modifications to the J V M . 31 4.3.1 Design To solve the problems noted above, Mob i l e J makes use of a hierarchy of wrapper classes, instances of which reference real Java arrays. These wrapper classes include constructors for creating "wrapped" array objects, as well as accessor methods for setting and getting array elements. A proxy class is also created based on the wrapper class. Therefore, all Java array operations can be converted to method invocations through a proxy object, as wi th field access operations on normal Java objects. The J V M creates a different array class for each combinat ion of array base type and number of dimensions. For example, a two dimensional array of integers is of a different class than a single dimensional array of integers. To mimic this wi th the array wrapper class, the Instrument ut i l i ty creates multiple wrapper classes which inherit from the base array wrapper class, ub c m j . a r r a y . A r r a y W r a p p e r . A s code is being instrumented, the Instrument tool keeps track of al l references to arrays and, after finishing the main instrumentation process, creates any A r r a y W r a p p e r sub-classes and proxy classes required. A r r a y W r a p p e r sub-classes are named according to the formula: _ < n > _ < t > < c o m p o n e n t _ c l a s s _ n a m e > where: • <n> is the number of dimensions of this array class • <t> is either a pr imit ive type descriptor, if the array's component 's are pr im-itives, or " L " if the array's components are objects 32 • < c o m p o n e n t _ c l a s s _ n a m e > is the fully qualified class name of the object type component, wi th all periods (.) replaced with underscores (_); the < c o m p o n e n t _ c l a s s _ n a m e > is only needed (and used) if the array component type is an object type Though many A r r a y W r a p p e r sub-classes are created, all functionality is in-herited from the A r r a y W r a p p e r class-the sub-classes exist only to distinguish array types to the J V M . W h e n checking if one array variable is assignment compatible wi th another array variable, Java checks the assignment compatibi l i ty of the arrays ' elements. To conform wi th this definition of compatibi l i ty , the inheritance hierarchy of M o b i l e J array wrapper classes is as displayed in Figure 4.1. This inheritance hierarchy ensures that references to array wrapper objects are assignment compatible in the same way as instances of normal Java arrays. There is one l imi ta t ion of this design1 worth noting. Java interfaces can inherit from multiple other interfaces, therefore, for array wrapper classes to wrap arrays of interfaces, they would need to inherit from multiple other classes. Java only allows single inheritance for classes, therefore a M o b i l e J array wrapper class which wraps an interface array may only inherit from a single interface array wrapper class. The Instrument ut i l i ty selects the first inherited interface declared as the one inherited by the array wrapper class. 33 ArrayWrapper _1_Lj ava_lang_Obj ect Y _1_Lj ava_util_Vector _1_L j ava_util_Stack _2_L j ava_lang_Obj ect Y _ 2_Lj ava_util_Vector _2_Lj ava_util_Stack 1 B 1 C 1 -D arrays 1 D 2 B 2 C 2-D arrays 2 D Figure 4.1: Array Wrapper Class Hierarchy 34 Multidimensional Arrays In Java, multidimensional arrays are created as arrays o f arrays, i.e., elements of multidimensional arrays are other arrays. For example, a two dimensional array twoD could be assigned as an element of the three dimensional array t h r e e D : i n t [ ] [ ] twoD = new i n t [10] [10] ; i n t [] [] t h r e e D = new i n t [10] [] [] ; t h r e e D [ 5 ] = t w o D ; The data structure arrangement and element types for a wrapped three d i -mensional array of integers are pictured in Figure 4.2 (page 36). Because the sub-arrays of a mult idimensional array are also arrays, and han-dled by reference, when wrapped, the elements of lower dimensional sub-arrays of a multidimensional array are instances of V A r r a y W r a p p e r sub-classes. 4.3.2 Creation Java arrays may be created by the J V M using three different bytecode instructions: n e w a r r a y , a n e w a r r a y , and m u l t i a n e w a r r a y . The instrumentat ion and correspond-ing A r r a y W r a p p e r constructor used when replacing each instruction in instrumented code is discussed below. Creation with n e w a r r a y The simplest form of array creation is done wi th n e w a r r a y , which creates a single dimension array of pr imit ive component type, n e w a r r a y takes the top stack word, n, and creates an array of n whose components wi l l be of a pr imit ive type indicated by a byte which is part of the instruct ion. 35 i ( V _ 2 _ I \ / 1 1 t / \ _2. _ I V ) v i i_ .1 ) l 1 t \ _ 1 _ I / \ V_3 _ I / 1 1 t / \ _3. _ I V / V _ 2 _ I i i t _2 . _ I \ ) / V _ 2 _ I \ i i t / _2. _ I \ Key: object object reference ** indirect reference array of object references array of integers Figure 4.2: D a t a Structure and Element Types of a Wrapped Three Dimensional A r r a y of Integers 36 new <VArrayWrapper-sub-class> dup_xl swap ldc <type-code> <load-obj ect-host> invokespecial <VArrayWrapper-sub-class>(IILjava/lang/String;) Figure 4.3: Instructions Replacing newarray To emulate this instruction using the ArrayWrapper class, the newarray instruction is replaced wi th the instructions shown in Figure 4.3. The new instruction creates an uninit ial ized instance of the appropriate VArrayWrapper sub-class. The dup_xl and swap instructions arrange the stack such that the reference to the VArrayWrapper object is below the array size (in-teger), placed on the stack by code immediately preceding this. The first ldc in -struction loads an integer, the array type-code, indicat ing the array component 's pr imit ive type, and the instruction indicated by <load-obj ect-host> is either an ldc instruction or a getstatic instruction which loads the host name on which this array should be created (usually it wi l l be "localhost") . F inal ly , the last instruc-tion invokes the appropriate VArrayWrapper constructor to initialize the array. The ArrayWrapper constructor which is eventually invoked creates a real Java array of the type specified by the <type-code> value. Creation with anewarray The second Java bytecode instruction used to create arrays is the anewarray in -struct ion. This instruction is used to create a single dimension array of objects, anewarray takes the top stack word, n, and creates an array of n elements whose component type is indicated by a reference, as part of the instruction, to a Class 37 new < V A r r a y W r a p p e r - s u b - c l a s s > d u p _ x l swap l d c < b a s e - t y p e - s t r i n g > < l o a d - o b j e c t - h o s t > i n v o k e s p e c i a l < V A r r a y W r a p p e r - s u b - c l a s s > ( I L j a v a / l a n g / S t r i n g ; L j a v a / l a n g / S t r i n g ; ) V Figure 4.4: Instructions Replacing a n e w a r r a y entry in the constant pool. A s shown in Figure 4.4 (page 38), the code which emulates the a n e w a r r a y instruction is very similar to the code which emulates n e w a r r a y . Therefore, only the differences wi l l be discussed below. Instead of indicat ing the array's component type by a type code value passed to the A r r a y W r a p p e r constructor, the bytecode passes a " < b a s e - t y p e - s t r i n g > " . This is a Java string indicat ing the appropriate M o b i l e J class to use for components of the array. Usual ly this wi l l be a proxy class (except where a proxy class is not used in M o b i l e J , as discussed previously). If the a n e w a r r a y instruction is being used to create the first dimension of a mult idimensional array, the component type wi l l be an appropriate sub-class of V A r r a y W r a p p e r . The A r r a y W r a p p e r constructor creates a real Java array of the type specified by the < b a s e - t y p e - s t r i n g > . C r e a t i o n w i t h m u l t i a n e w a r r a y The final instruction which can create arrays in Java bytecode is the m u l t i a n e w a r r a y instruction, which is used to create a multi-dimensional array, m u l t i a n e w a r r a y cre-ates an array of n dimensions where n is indicated as part of the instruction. A l s o as part of the instruction is a reference to a Class constant pool entry indicat ing the 38 i s t o r e 2 5 5 i s t o r e 2 5 4 i s t o r e < 2 5 5 - ( n - l ) > i s t o r e <255-n> new < V A r r a y W r a p p e r - s u b - c l a s s > dup i l o a d <255-n> i l o a d < 2 5 5 - ( n - l ) > i l o a d 2 5 4 i l o a d 2 5 5 l d c < w r a p p e r - b a s e - t y p e - s t r i n g > l d c < b a s e - t y p e - s t r i n g > < l o a d - o b j e c t - h o s t > i n v o k e s p e c i a l < V A r r a y W r a p p e r - s u b - c l a s s > ( I i . . .In L j a v a / l a n g / S t r i n g ; L j a v a / l a n g / S t r i n g ; ) V Figure 4.5: Instructions Replacing m u l t i a n e w a r r a y type descriptor for the array being created. The instruction expects n integers on the top of the stack, each of which indicates the size of one dimension of the array. To emulate this instruction using the A r r a y W r a p p e r class, the m u l t i a n e w a r r a y instruction is replaced with the instructions shown in Figure 4.5 (page 39). The m u l t i a n e w a r r a y instruction is more awkward to emulate because at the point where the instruction is encountered in bytecode, n (where 1 < n < 255) integer words are on top of the stack, one for each dimension of the array. These integers, representing the size of each array dimension, must be passed as arguments to a V A r r a y W r a p p e r constructor, however, to do so, a reference to the uninit ial ized V A r r a y W r a p p e r object must be placed beneath the integers. The solution taken is to first store the n integers in local variables numbered from 255 downward, create the V A r r a y W r a p p e r instance, and then load the n integers 39 back on to the stack. Th i s assumes the method involved does not use more than (255 - n) local variable slots. It also assumes that A r r a y W r a p p e r has as many constructors of this type as the number of dimensions of the maximal ly dimensioned array instance that needs to be created. 2 After re-loading the n integers, the instrumented code loads a " w r a p p e r - b a s e - t y p e - s t r i n g > " from the constant pool . Th is is a Java string which is used by the A r r a y W r a p p e r constructor in creating instances of the appropriate V A r r a y W r a p p e r sub-class which wi l l be elements of the created A r r a y W r a p p e r in-stance (because the created array is mult idimensional) . Th i s str ing is the same as the A r r a y W r a p p e r sub-class name, but without the " _<n>" (number of dimensions prefix) which wi l l be different for each dimension of the array. This str ing could be computed at run t ime by the A r r a y W r a p p e r constructor, but it is more efficient to compute it statically, at instrumentation time, and pass it recursively as the multi-dimensioned array is created. The " < b a s e - t y p e - s t r i n g > " passed to the constructor is the same as that which is passed when emulating the a n e w a r r a y instruct ion, except in this case the string usually indicates another V A r r a y W r a p p e r sub-class, which would be the type of elements in the second dimension of the array being created. The A r r a y W r a p p e r constructor recursively creates the n dimensions of the multi-dimensional array. 4.3.3 Access The J V M has a number of instructions which are used to load elements from an array to the stack, and store elements from the stack to a part icular array element. There is also an instruction to retrieve the length of an array. There are different 2In the current implementation of MobileJ, ArrayWrapper has enough constructors for a ten dimensional array, though more could easily be added, up to the required 255. 40 E l e m e n t T y p e I n s t r u c t i o n M e t h o d a n d S i g n a t u r e integer i a l o a d g e t l n t ( l ) l i a s t o r e s e t I n t ( I I ) V long l a l o a d g e t L o n g ( I ) J I a s t o r e s e t L o n g ( I J ) V float f a l o a d g e t F l o a t ( I ) F f a s t o r e s e t F l o a t ( I F ) V double d a l o a d g e t D o u b l e ( I ) D d a s t o r e s e t D o u b l e ( I D ) V object reference a a l o a d g e t ( I ) L j a v a / l a n g / O b j e c t ; a a s t o r e s e t ( I L j a v a / l a n g / O b j e c t ; ) V byte/boolean b a l o a d g e t B y t e ( I ) B b a s t o r e s e t B y t e ( I B ) V character c a l o a d g e t C h a r ( I ) C c a s t o r e s e t C h a r ( I C ) V short s a l o a d g e t S h o r t ( I ) S s a s t o r e s e t S h o r t ( I S ) V a r r a y l e n g t h g e t L e n g t h O I Table 4.1: Java A r r a y Access Instructions and Their Corresponding A r r a y W r a p p e r Methods load and store instructions for each Java primitive type (except boolean values, which use the instructions for byte types), and for object reference elements. To mimic the array access instructions, the A r r a y W r a p p e r class provides corresponding methods to load from and store to the underlying Java array which its instances wrap. It also provides a g e t L e n g t h method which may be used to get the size of the array. The Instrument tool replaces al l array access instructions with an invocation of their corresponding A r r a y W r a p p e r method. Table 4.1 summarizes the methods which replace array access instructions. 41 4.4 Method Invocation and Return 4.4.1 M e t h o d Headers In addit ion to a method's bytecode, various entities of a Java class file method table are changed when instrumented for use with M o b i l e J ; these changes are described in this section. Names W h e n the Instrument tool creates a proxy class, the names and signatures of its methods are made the same as its corresponding "real" class. However, as all proxy objects inherit from the class V O b j e c t , any method names which are the same as methods of V O b j e c t must be changed. 3 M e t h o d names which would potentially override methods of V O b j e c t are changed by prepending " m j _ " to them in the in-strumented class and its proxy class. Exceptions to this are the standard t o S t r i n g and c l o n e methods which may be overridden in the proxy class. One other exception to the method naming convention relates to Java ex-ception classes and is described in Section 4.7.1, on page 58. Signatures M o s t of the objects handled by instrumented code are referenced through a proxy object, thus method parameter and return types are changed in the instrumented code. This requires changing the signature of al l methods which accept or return objects, including arrays. 3This is not strictly true: actually, any methods with the same name and the same parameters must have their names changed in the instrumented class; otherwise, the methods in sub-classes would override the methods of VObject. For ease of implementation, however, the current Instru-ment utility only checks the method's name. 42 A l l Java primit ive type descriptors in a method's signature are left unchanged as these parameters are passed by value. A r r a y type descriptors are changed to their equivalent array proxy class type descriptor (as described in Section 4.3, page 31). A l l other object type descriptors are changed to descriptors of their equivalent proxy object type, except for those classes without proxy classes, in which case the de-scriptor is changed to one of the corresponding instrumented class. Descriptors for j a v a . l a n g . O b j e c t are left unchanged. Access Restrictions Java class methods may be designated " p r i v a t e " , " p r o t e c t e d " , " p u b l i c " , or left wi th no designation, meaning "package" level access for the method. In addi t ion, methods may be either instance methods or static (class) methods. M o b i l e J requires that all instance methods and constructors be made p u b l i c . Th i s comes as a direct result of using proxy objects for location transparent method invocat ion. Because a proxy object is of a different class than its corresponding "real" (instrumented) object, access to its methods cannot be restricted using or-dinary method access flags, as wi th ordinary Java objects: the J V M doesn't know that the proxy objects should be regarded as being in the same "protection domain" as the non-proxy objects when determining i f a method should be accessible from a certain context. 43 For example, if a method of class f o o accepts " b a r " , an argument of class f o o , this method is allowed to invoke any private instance method of the b a r because it is of the same class as itself. However, when instrumented, the argument b a r takes on the type Vfoo (the proxy class of foo ) ; thus, to the J V M , its private methods are no longer accessible to the method. M a k i n g all instance methods public gets around this problem. Exceptions Thrown A s Java exception classes are instrumented, the exceptions thrown by a method also have their names changed to those of the new, instrumented exception types. 4.4.2 Invocation and Return General Cases W h e n instrumenting a bytecode instruction which invokes a method, the invoking instruction must be made to reference a new Methodref entry in the constant pool whose referenced class, method name, and method signatures have been changed according to Mobi l e J ' s conventions. These conventions have been previously de-scribed in sections 4.2.1 (page 30) and 4.4.1 (page 42), and wi l l not be described here. Generally, this means that most method invocations are made to go through a proxy object, also described previously. However, there are a number of special cases which must be handled for method invocation to function properly and follow the semantics of normal Java method invocation; these are described below. 44 Invocat ion and R e t u r n F r o m W i t h i n an Instance M e t h o d M o s t references to objects handled by instrumented code in M o b i l e J are to proxy objects. However, al l instance methods, including those in instrumented classes, are impl ic i t ly passed a reference to the object which is the target of the invocation (the " t h i s " parameter) by the J V M . W i t h i n instrumented classes, this object wi l l never be a proxy object, and must be handled differently when being passed as an argument in further method invocations, used as the target of an invocation, or returned from the instance method. In the first and last instances, the reference to t h i s must be converted to a reference to a proxy object (which, in turn, references t h i s ) ; in the second case, the method referenced must be in a "real" class and not a proxy class as wi th most method invocations. Because static analysis of where the t h i s reference is being used in method bytecode is quite difficult (and impossible in the general case), the Instrument ut i l i ty inserts bytecode to perform run t ime checks for usages of t h i s in cases where it can determine that the check is necessary. W h e n checking i f t h i s is passed as an argument to a method, the types of all method parameters, as specified in the method's signature, are check to see if they are the same as or super classes of the invoking method's class (i.e., the class of the t h i s object). If any parameters could be a reference to t h i s (based on their type), code to perform a run t ime check for t h i s being passed as a parameter is inserted. Figure 4.6 shows the bytecode that is inserted immediately before the method invocation instruct ion. The c h e c k F o r T h i s P a r a m method is a native static method in the Mob i l e J Runt ime. Th i s method scans the Java stack for references to t h i s and replaces them wi th references to proxy objects by invoking V O b j e c t . f o r D b j e c t which creates an 45 l d c < s t a c k B i t F i e l d > b i p u s h <numWords> i n v o k e s t a t i c u b c / m j / M o b i l e J a v a / c h e c k F o r T h i s P a r a m ( I I ) V Figure 4.6: Runt ime Check For " t h i s " A s a Parameter: < s t a c k B i t F i e l d > and <numWords> are integers determined by the Instrument uti l i ty. appropriate proxy object for a particular "real" object. The c h e c k F o r T h i s P a r a m method is dependant on the particular J V M implementat ion running M o b i l e J . 4 Because it needs quick access to words on the Java stack below the top one, this method is implemented in C , and is part of the M o b i l e J Nat ive Library . The < s t a c k B i t F i e l d > and <numWords> integer values are determined by the Instrument ut i l i ty by analysing the parameters of the method being invoked. < s t a c k B i t F i e l d > is an integer bit-field specifying which words on the Java stack may hold references to the t h i s parameter (as determined by the analysis of param-eter types described above). The c h e c k F o r T h i s P a r a m method only checks words on the stack for which the corresponding bits of < s t a c k B i t F i e l d > are on. <numWords> indicates the max imum depth, in words, c h e c k F o r T h i s P a r a m should scan the stack looking for a reference to t h i s . Using these parameters, the stack may be efficiently scanned for references to t h i s passed in a method invocat ion. Because a reference to t h i s can also be returned from an instance method, the Instrument tool inserts code to ensure that these are converted to refer-ences to proxy objects when returned by the a r e t u r n instruct ion. Since the c h e c k F o r T h i s P a r a m method works perfectly well for this case as well, the code in Figure 4.6 is inserted immediately before the a r e t u r n instruction i f the Instru-ment tool determines, by comparing the return type in the method's signature wi th 4The current version of MobileJ supports version 1.1.5 of Sun Microsystem's implementation of the VM on Solaris and a port of Sun's VM on Linux. 46 bipush <n> i nvokes ta t i c ubc/mj /Mobi leJava/checkForThisTarget ( I )Z i f e q L a b e l l i n v o k e v i r t u a l < ' t h i s ' ob ject method> goto Label2 L a b e l l : i n v o k e v i r t u a l <proxy object method> Labe l2 : Figure 4.7: Runt ime Check For " t h i s " A s a M e t h o d Invocation Target the method's class, that the reference returned could possibly be a reference to t h i s . In this case, <s tackBi tF ie ld> and numWords are both equal to 1. W h e n checking if t h i s is the target of a method invocation, the Instrument tool checks if the method is in the same class or a super-class of the current class. If this is the case, then it is possible that the target of the invocation (the object whose method is being invoked) is the current method's object, i.e., the t h i s ob-ject. Figure 4.7 (page 47) shows the bytecode that replaces the method invocation instruction in this case. A s wi th the checkForThisParam method, the checkForThisTarget method is a native static method in the M o b i l e J Runt ime. This method examines the Java stack word indicated by its integer argument, returning the boolean value t rue i f this word is a reference to t h i s , and f a l s e if not. The Instrument tool determines which word could be a reference to t h i s by counting the number of words making up parameters according to the method's signature. The target of the invocation is one word below the first argument word. 47 If the target of the invocation is t h i s , the first invocation instruct ion, which references a method in the same class as the current method wi l l be executed. Otherwise, the second invocation instruct ion, which references a method in a proxy class, wi l l execute. Static Method Invocation Stat ic (or class) methods are invoked in much the same way as instance methods, except that they are not passed an instance of the method's class. A s discussed in Section 2.2 (page 15), static method invocations need not go through a proxy class, but, rather, are called directly. Stat ic methods are invoked wi th the i n v o k e s t a t i c instruction, and each instance must have its referenced class and method signature changed by the Instrument tool . The tool changes referenced class names to their corresponding instrumented class names as well as changing the types of parameters according to the Mob i l e J conventions discussed earlier (see Section 4.2.1 for details). Other Special Cases A part icular case of invoking wi th in an instance method where the target is t h i s happens when a constructor calls a super-class constructor. The Java Language Specification [GJS96] states that the first statement in a constructor must be a call to a super-class constructor, and even i f it does not exist in the source code, a call to the super-class constructor wi th no arguments is inserted impl ic i t ly in the bytecode by the compiler. The Instrument tool can thus determine when this is happening in a construc-tor 's bytecode and ensure that the constructor in a M o b i l e J instrumented class is called, rather than a constructor in a proxy class as would happen without checking 48 d u p i n s t a n c e o f V O b j e c t i f n e L a b e l l i n v o k e s t a t i c VOb j e c t / f o r O b j e c t ( L j a v a / l a n g / O b j e c t ; ) L V O b j e c t ; L a b e l l : Figure 4.8: Bytecode Inserted After an Invocation of c l o n e . for this special case. Another case of method invocation which is handled as a special case when instrumenting bytecode is invocation of an object's g e t C l a s s method. Because this method, when invoked on a proxy object, would return the real Java C l a s s object representing the proxy's class, it must be changed such that an instance of u b c . m j . J a v a . l a n g . V C l a s s is returned instead. The Instrument tool replaces the invocation of g e t C l a s s wi th an invocation of the static method f o r O b j e c t ( L j a v a / l a n g / O b j e c t ; ) L u b c / m j / j a v a / l a n g / V C l a s s ; in the instru-mented version of J a v a . l a n g . C l a s s . Th is method is added to the instrumented version of J a v a . l a n g . C l a s s by the Instrument tool , as wi l l be described in Section 4.7.4 (page 63). A th i rd case of method invocation handled as a special case is invocation of an object 's c l o n e method. The Instrument tool inserts code after the invocation of c l o n e to ensure that the object returned is an instance of a proxy class; these instructions are displayed in Figure 4.8. This code checks i f the instance returned by c l o n e is an instance of V O b j e c t , the super-class of all proxy objects. If not, it calls the static method f o r O b j e c t to convert the reference from a "real" Java object to a reference to a proxy object. 49 < l o a d - o b j e c t - h o s t > i n v o k e s p e c i a l V O b j e c t / < i n i t > ( . . . L j a v a / l a n g / S t r i n g ; ) V dup i n v o k e s t a t i c u b c / m j / M o b i l e J a v a / r e g i s t e r O b j e c t ( L V O b j e c t ; ) V Figure 4.9: Bytecode Instrumentation of Constructor Invocation If the invocation is made to the c l o n e method in j a v a . l a n g . O b j e c t v ia an i n v o k e s p e c i a l instruction, the Instrument tool assumes that a clone of the current object (the t h i s object) is created and omits the type-checking code, inserting the call to f o r O b j e c t directly after the call to c l o n e . The final special case of method invocation is invocation of an object's t o S t r i n g method. This wi l l be discussed in Section 4.7.2 (page 59). 4.5 Object Creation and Initialization Objects are allocated in Java bytecode by the new instruct ion. Th i s instruction references a Class entry in the constant pool , describing the class of the object to be created. The Instrument tool changes this class to the appropriate proxy class when it encounters a new instruct ion. After al locating a new object wi th new, one of the object's constructors is called to initialize the object. In addit ion to changes made to the bytecode because this is a method invocation (as described in Section 4.4.2, page 44), the Instrument tool must decide on what machine the object should be created, and pass a reference to the proxy object to the M o b i l e J Runt ime system. Figure 4.9 shows an example of a constructor invocation after instrumentat ion. If the type of object being init ialized has been designated as being created at 50 either the client or server host, the g e t s t a t i c instruction retrieves the appropriate host name and port number from the Mob i l e J Runt ime. Otherwise the object is created on the current host, thus < l o a d - o b j e c t - h o s t > becomes l d c " l o c a l h o s t " . The final parameter of a proxy object's constructor is always a s t r ing in which is passed the host name and port number of the location to create the object at. F ina l ly , the Instrument tool adds a call to the r e g i s t e r O b j e c t method in the Mob i l e J Runt ime so that it can move the object in the future according to its object placement policy. 4.6 Field Access 4.6.1 F i e l d Signatures A s M o b i l e J applications handle objects through proxy objects, the type signature of object fields, including arrays, must be changed. The modification of field type signatures is exactly the same as for that of method signatures, as described in Section 4.4.1 (page 42), i.e., most object types are changed to their corresponding proxy object type. 4.6.2 Accessor Me thods W h e n the Instrument tool examines a class, it adds two accessor methods for every field (both static and non-static); these are used to set and retrieve field values as wi l l be described in the next two sections. 51 Stat ic fields: g e t S t a t i c _ < c l a s s - n a m e > _ < f i e l d - n a m e > p u t S t a t i c _ < c l a s s - n a m e > _ < f i e l d - n a m e > Non-stat ic fields: g e t F i e l d _ < c l a s s - n a m e > _ < f i e l d - n a m e > p u t F i e l d _ < c l a s s - n a m e > _ < f i e l d - n a m e > Figure 4.10: Static and Non-Stat ic F ie ld Accessor M e t h o d Names F ie ld accessor methods are named according to the general form shown in Figure 4.10. Here < c l a s s - n a m e > is the fully qualified class name of the class being instrumented wi th all periods (.) replaced wi th underscores (_). < f i e l d - n a m e > is the name of the field. 4.6 .3 Static Fields The J V M has two instructions for accessing static fields: g e t s t a t i c and p u t s t a t i c . Because of the design of static da ta in Mob i l e J (Section 2.2, page 15), there are six different cases of use which are instrumented differently: Initializing p u t s t a t i c Of Object Fields A n "ini t ia l iz ing p u t s t a t i c " instruction is one which stores the ini t ia l value of a static field, and is contained in a class' static initializer method (named " < c l i n i t > " ) . This method is run impl ic i t ly by the J V M when the class is loaded. Figure 4.11 shows the bytecode which replaces an instance of an ini t ia l iz ing p u t s t a t i c instruc-tion which works wi th Object fields. The ini t ial izat ion of static object data wi th in a static intializer method hap-pens in two steps: first the object is created and its constructor invoked. For an 52 g e t s t a t i c u b c / m j / M o b i l e J a v a / i s S t a t i c H o s t i f n e L a b e l l p o p g e t s t a t i c u b c / m j / M o b i 1 e J a v a / O T H E R _ H O S T i n v o k e s t a t i c g e t S t a t i c _ < c l a s s - n a m e > _ < f i e l d - n a m e > ( ) L a b e l l : p u t s t a t i c < s t a t i c - f i e l d > Figure 4.11: Bytecode Replacing an Ini t ial izing p u t s t a t i c O f Object Fields instrumented class, this wi l l (generally) create a reference to a proxy object on the top of the stack. Second, this reference is stored in a static variable using the p u t s t a t i c instruct ion. This second step happens differently depending on if the static init ializer is executing on the static host or not. (This is tested for using the first two instructions in Figure 4.11.) If the static initializer is executing on the static host, the reference to the proxy object is copied to the static variable wi th p u t s t a t i c just as it would be in non-instrumented code. However, if the static initializer is executing on the non-static host, the reference to the proxy object is popped off the stack and the proxy object for this static field is obtained from the static host by invoking a g e t S t a t i c _ . . . type accessor method. The returned proxy object, which references the "real" object created by the static init ializer on the static host, is stored in the local static variable. Th i s design has the disadvantage that ini t ial izat ion of static objects happens twice, wi th one copy not used. However, given the inherent difficulties of analyzing the da ta flow of methods, this solution was chosen. It is difficult to determine, in the general case, where a reference to an object wi l l eventually be stored in a method. 53 ( l d c < s t a c k B i t F i e l d > b i p u s h <numWords> i n v o k e s t a t i c u b c / m j / M o b i l e J a v a / c h e c k F o r T h i s P a r a m ( I I ) V d u p g e t s t a t i c u b c / m j / M o b i l e J a v a / 0 T H E R _ H 0 S T i n v o k e s t a t i c p u t S t a t i c _ < c l a s s - n a m e > _ < f i e l d - n a m e > ( . . . ) p u t s t a t i c < f i e l d > Figure 4.12: Bytecode Replacing a Non-Ini t ia l iz ing p u t s t a t i c O f Object Fields I n i t i a l i z i n g p u t s t a t i c o f P r i m i t i v e F i e l d s Since pr imit ive type fields are handled by value and not reference, their ini t ia l izat ion is t r iv i a l . The Instrument tool does not need to change the p u t s t a t i c instruction which initializes a primitive static field. In effect, these fields are replicated on each M o b i l e J host. N o n - I n i t i a l i z i n g p u t s t a t i c o f O b j e c t F i e l d s A p u t s t a t i c instruction not wi th in a static intializer method which operates on an object type field must be handled differently than i f it were in a static intializer. The code which replaces such an access is shown in Figure 4.12. The first three instructions in Figure 4.12 are the same as those used to check if t h i s is being passed as a parameter in a method invocation. It is pos-sible for them to be necessary here under the same circumstances as discussed in Section 4.4.2 (page 44) because the p u t s t a t i c instruction is being replaced wi th a method invocation. A t the point of the dup instruct ion, the top stack word wi l l be a reference to a proxy object. The remaining instructions store a reference to the proxy object on both the opposite Mob i l e J host, and the current host. F i r s t a p u t s t a t i c . . . style accessor method is invoked on the opposite host, storing a reference there, and 54 finally the p u t s t a t i c instruction stores a reference to the proxy on the local host. N o n - I n i t i a l i z i n g p u t s t a t i c o f P r i m i t i v e F i e l d s A p u t s t a t i c instruction not wi th in a static intializer method which operates on a primit ive type field must be handled differently than i f it were in a static intializer. The code which replaces such an access is shown in Figure 4.13. This code simply invokes the appropriate p u t S t a t i c _ . . . style method on the static host to change the field value. O b j e c t T y p e g e t s t a t i c Other than changing the type descriptor referenced in the instruct ion, instances of g e t s t a t i c which operate on object type fields are left alone by the Instrument tool . Once init ial ized, static object type fields on either M o b i l e J host are proxy objects which refer to the same "real" object. Therefore, a reference to the proxy object may be obtained locally, wi thout invoking an accessor method. P r i m i t i v e T y p e g e t s t a t i c The bytecode which replaces an instance of g e t s t a t i c which operates on a pr im-itive type field is shown in Figure 4.14. This code s imply invokes the appropriate g e t s t a t i c . . . style method on the static host to retrieve the field value. g e t s t a t i c u b c / m j / M o b i l e J a v a / S T A T I C _ H O S T i n v o k e s t a t i c p u t S t a t i c _ < c l a s s - n a m e > _ < f i e l d - n a m e > ( ) Figure 4.13: Bytecode Replacing a Non-Ini t ia l iz ing p u t s t a t i c O f P r imi t ive Fields 55 g e t s t a t i c u b c / m j / M o b i l e J a v a / S T A T I C _ H O S T i n v o k e s t a t i c g e t S t a t i c _ < c l a s s - n a m e > _ < f i e l d - n a m e > ( ) Figure 4.14: Bytecode Replacing a g e t s t a t i c O f Pr imi t ive Fields 4.6.4 I n s t a n c e Fields The J V M has two instructions for accessing object fields: g e t f i e l d and p u t f i e l d . These instructions must be replaced by method invocations so that field access can be made to go through a proxy object. General Case Generally, each instance of p u t f i e l d is replaced wi th an invocation of a p u t F i e l d _ . . . style accessor method. Similarly, each instance of a g e t f i e l d is replaced wi th an invocation of the appropriate g e t F i e l d _ . . . accessor method. In this way, field accesses are made to go through proxy objects. There are two special cases which must be handled somewhat differently; these are explained below. p u t f i e l d with " t h i s " The first special case of instance field access has to do wi th the possibility of storing a reference to t h i s in a field. The Instrument tool checks all instances of p u t f i e l d within an instance method to see, based on the field type and type of t h i s , i f a reference to t h i s could be stored in the field by the p u t f i e l d instruct ion. If this is possible, the Instrument tool adds bytecode to perform a runtime check for this condit ion. Th i s is similar to the check inserted to ensure that a reference to t h i s passed in a method invocation is converted to a reference to a proxy object (see 56 bipush <n> i nvokes ta t i c ubc/mj /Mobi leJava/checkForThisTarget ( I )Z i f e q L a b e l l g e t f i e l d <f ie ld> goto Label2 L a b e l l : i n v o k e v i r t u a l g e t F i e l d _ . . . ( ) Labe l2 : Figure 4.15: Runt ime Check For " t h i s " A s a F ie ld Access Target Section 4.4.2, page 44). In the case of put f i e l d , the code in Figure 4.6 (page 46) is inserted just before the invocation of the appropriate pu tF ie ld_ . . . accessor method. Access of F i e l d in " t h i s " If the Instrument tool determines from the class referenced in the put f i e l d or g e t f i e l d instruction that the field being accessed may be in the current, or t h i s , object, some instructions must be inserted to check for this condit ion at runtime. Th i s is done because access of fields of the current object can be done without going through a proxy object. Th is is similar to the check done before some method invocations where the invocation might go to the current object (see Section 4.4.2, page 44). Figure 4.15 shows the bytecode replacing an instance of a field access where the access could possibly be to a field of t h i s . The same M o b i l e J Runt ime method, checkForThisTarget, is called to check i f the word at location <n> is a reference to t h i s . If it is, a g e t f i e l d instruction is used to retrieve the field value, otherwise a ge tF ie ld_ . . . method is called to retrieve the field value v i a a proxy object. Th is runtime check is also used for similar instances of put f i e l d . 57 4.7 Miscellaneous Changes and Exceptional Cases 4.7.1 E x c e p t i o n C l a s s e s A s noted earlier, in Section 4.2.1 (page 30), Java exception classes (i.e., J a v a . l a n g . T h r o w a b l e and its subclasses) have corresponding instrumented ver-sions created by the Instrument tool . However, proxy classes are not created for these classes because of the way they are used in Java applications. F i r s t , instances of exception classes are thrown by the a t h r o w bytecode instruction which expects a j a v a . l a n g . T h r o w a b l e object to th row; 5 proxy classes cannot be sub-classes of J a v a . l a n g . T h r o w a b l e . Second, exception objects are typical ly used as short-lived, error status carrying objects, therefore there is l i t t le need for their location to be transparent to application programs. W h e n instrumenting the Java Class Library , the Instrument tool creates in -strumented version of all exception classes, including j a v a . l a n g . T h r o w a b l e . F i g -ure 4.16 shows the inheritance hierarchy of instrumented exception classes in M o -bi leJ . A l l instrumented exception classes inherit from their appropriate (instru-mented) super-class, except u b c . m j . j a v a . l a n g . T h r o w a b l e , which inherits from j a v a . l a n g . E x c e p t i o n . 6 Th is allows instances to be thrown wi th a t h r o w . 5The VM used for developing MobileJ, a port of Sun's version 1.1.5 JDK, actually allows any type of object to be thrown, i.e., it does not do a runtime check of the object type when executing the athrow instruction. This would, however, cause bytecode verification to fail. 6These classes could inherit from java.lang.Throwable, however a limitation of the cur-rent MobileJ Distribution Layer implementation (i.e., Voyager) requires them to inherit from java.lang.Exception. 58 j ava.lang.Throwable j ava.lang.Exception j ava.lang.Error V ubc.mj.java.lang.Throwable ubc.mj.java.lang.Exception ubc.mj.java.lang.Error \i \i instrumented instrumented exception classes error classes Figure 4.16: Class Hierarchy For Instrumented Except ion Classes To ensure that methods in u b c .mj . J a v a . l a n g . T h r o w a b l e don' t over-ride those in J a v a . l a n g . T h r o w a b l e , certain method names have their names changed by prepending " m j _ " to them; these methods are: f i l l l n S t a c k T r a c e , g e t L o c a l i z e d M e s s a g e , a n d g e t M e s s a g e . 4.7.2 Strings Introduction W h i l e most classes instrumented for use wi th M o b i l e J have proxy classes, the instru-mented version of J a v a . l a n g . S t r i n g does not. Since Java strings are immutable , they may be passed by value in method invocations which traverse machine bound-aries without interfering wi th Java invocation semantics. Furthermore, s tr ing in-stances are often small , short-lived objects, and removing the need for invocations to go through proxy objects improves the performance of str ing handling code. Though it does not require a proxy class, the str ing class does need to 59 be instrumented. The class J a v a . l a n g . S t r i n g contains methods wi th parame-ters, which, when instrumented, have their types changed to proxy classes. If J a v a . l a n g . S t r i n g was not instrumented, these methods would be incompatible with other instrumented bytecode. It should be noted that while the class u b c . m j . J a v a . l a n g . S t r i n g does not have a corresponding proxy class, its underlying character array field is wrapped in an V A r r a y W r a p p e r subclass, and thus accessed through a proxy object. Conversion Methods The Instrument tool adds two static conversion methods to the class u b c . m j . J a v a . l a n g . S t r i n g for converting between instances of J a v a . l a n g . S t r i n g and instances of u b c . m j . J a v a . l a n g . S t r i n g . These are used when loading str ing constants from the constant pool , when invoking t o S t r i n g methods, and in some native methods which accept str ing parameters. The first two cases are described in the following sections; the use wi th in native methods is pr imari ly of the t o R e a l S t r i n g method, converting instances of u b c . mj . j a v a . l a n g . S t r i n g to instances of j a v a . l a n g . S t r i n g . Th i s is done so that J N I functions may be used in Mob i l e J ' s Nat ive L ib ra ry which return the C "array of bytes" representation of a Java str ing instance. The f o r S t r i n g method is used to convert from a J a v a . l a n g . S t r i n g to a u b c . m j . j a v a . l a n g . S t r i n g . The signature and bytecode for this method is shown in Figure 4.17. This method works by converting the str ing to a character array, wrapping this character array in a proxy object, and invoking the appropriate con-structor of u b c . m j . j a v a . l a n g . S t r i n g . The t o R e a l S t r i n g method is used to convert from a 60 Signature: (Lj ava / l ang /S t r i ng ; ) Lubc /m j / j a v a / l a n g / S t r i n g ; Bytecode: new u b c / m j / j a v a / l a n g / S t r i n g dup new ubc/mj /a r ray /V_ l_C dup aload_0 i n v o k e v i r t u a l j a v a / l a n g / S t r i n g / t o C h a r A r r a y O [ C ldc_w " l o c a l h o s t " i nvokespec ia l ubc /mj /a r ray /V_ l_C/< in i t> ( L j a v a / l a n g / O b j e c t ; L j a v a / l a n g / S t r i n g ; ) V invokespec ia l ubc /m j / j ava / l ang /S t r i ng /< in i t > (Lubc /mj /a r ray /V_ l_C; )V are turn Figure 4.17: f o r S t r i n g M e t h o d Signature and Bytecode ubc.mj . j a v a . l a n g . S t r i n g to a j a v a . l a n g . S t r i n g . The signature and bytecode for this method is shown in Figure 4.18. Th i s method works by obtaining the underlying character array, offset value, and character count for the str ing, and passing them to the appropriate constructor of j a v a . l a n g . S t r i n g . String Constants The J V M has support for loading constant string values from the constant pool for a class. Us ing the l dc (or ldc_w) instruction and referencing a constant St r ing entry in the constant pool causes the J V M to create a new instance of j a v a . l a n g . S t r i n g and place a reference to it on the stack. These references to "real" Java strings must be converted to references to instances of ubc.mj . j a v a . l a n g . S t r i n g . Th i s is accomplished by inserting an in-vocation instruction which calls the f o r S t r i n g method described above. 61 Signature: ( L u b c / m j / j a v a / l a n g / S t r i n g ; ) L j a v a / l a n g / S t r i n g ; Bytecode: new j a v a / l a n g / S t r i n g dup aload_0 g e t f i e l d ubc /m j / j a va / l ang /S t r i ng / va l ue i n v o k e v i r t u a l ubc/mj/array/VArrayWrapper/getData ( )L java / l ang /Ob jec t ; aload_0 get f i e l d ubc/mj / j a v a / l a i i g / S t r i n g / o f f set aload_0 g e t f i e l d ubc /m j / j ava / l ang /S t r i ng /coun t invokespec ia l j ava / l ang /S t r i ng .< in i t > ( [C I I )V are turn Figure 4.18: t oRea lS t r i ng M e t h o d Signature and Bytecode toString Method Invocation The way the method t oS t r i ng , which returns the string representation of an object, is handled in Java requires special attention in M o b i l e J . Instrument-ing this method in the normal way causes its return type to be changed to ubc.mj . j a v a . l a n g . S t r i n g ; this causes a conflict wi th t o S t r i n g as defined in j ava . l ang .Ob jec t , from which all classes inherit . 7 Therefore, the return type for all t o S t r i n g methods instrumented for use wi th M o b i l e J is kept as a j a v a . l a n g . S t r i n g . Th i s requires a call to t o R e a l S t r i n g to be inserted in al l t o S t r i n g methods to convert its result to a "real" Java str ing, and a call to f o r S t r i n g to be inserted after all invocations of t o S t r i n g to convert the returned str ing back to a M o b i l e J s tr ing. This is because a method in a sub-class cannot have the same name and parameter types while also having a different return type as a method in a super-class; one cannot overload a method by only changing its return type. 6 2 4.7.3 T y p e Checking Instructions T w o bytecode instructions, which have not previously been mentioned, also need to be instrumented for use wi th M o b i l e J : c h e c k c a s t and i n s t a n c e o f . B o t h of these instructions reference a Class entry in the constant pool; the Instrument tool changes the class referenced such that it is the equivalent class used under M o b i l e J , which is usually a proxy class. 4.7.4 j a v a . l a n g . C l a s s and Reflect ion The capabilities in Java for reflection require special attention in order to func-tion correctly under M o b i l e J . The current implementation of M o b i l e J supports a certain amount of the reflection A P I found in the j a v a . l a n g . C l a s s and j a v a . l a n g . r e f l e c t . C o n s t r u c t o r classes, but this could be extended to fully sup-port the use of reflection under M o b i l e J . The current level of support is necessary in order to allow the j a v a . l a n g . S y s t e m class to load and basic applications to run. A l l loaded Java classes have a corresponding instance of j a v a . l a n g . C l a s s which represents them and can be used to invoke reflection capabilities. The na-tive methods which support reflection under M o b i l e J must also use C l a s s objects to reference classes as requested by M o b i l e J applications which use the Java reflec-tion A P I . However, to be consistent, instrumented M o b i l e J application code should only reference instances of the proxy class u b c . m j . j a v a . l a n g . V C l a s s , not "real" j a v a . l a n g . C l a s s objects. Thus, dur ing instrumentat ion of j a v a . l a n g . C l a s s , a private instance field, named r e a l C l a s s and of type j a v a . l a n g . C l a s s , is added in order to "wrap" the real C l a s s object. The native methods implementing reflec-tion under M o b i l e J know about this field and use it to invoke the underlying Java reflection A P I as needed. 63 The r e a l C l a s s field is assigned whenever a method that returns a C l a s s object is invoked. The most commonly used method for this purpose is the static method C l a s s . f o r N a m e which returns an instance of C l a s s given a particular class name, passed as a str ing. Since this is a native method, it needed to be reimple-mented for the corresponding instrumented version of class C l a s s . However, i f the new version of f o r N a m e returned the C l a s s object indicated by its s tr ing argument, it would become possible for the program to create an instance of this class, which would not be an instance of a proxy class. Therefore, the new version of f o r N a m e first converts the name passed to it into the equivalent Mob i l e J proxy class name, as described in Section 4.2.1. A j a v a . l a n g . C l a s s object representing the proxy class is then created. A new instance of u b c . m j . j a v a . l a n g . C l a s s is also created and the real C l a s s object assigned to its r e a l C l a s s field. F inal ly , a proxy instance referring to the u b c . m j . j a v a . l a n g . C l a s s object is then created, a reference to which is returned by f o r N a m e . A similar scheme is used to implement the Mob i l e J equivalent of the j a v a . l a n g . r e f l e c t . C o n s t r u c t o r class; a field named r e a l C o n s t r u c t o r of type j a v a . l a n g . r e f l e c t . C o n s t r u c t o r is added while instrumenting the C o n s t r u c t o r class. It is believed this method of "wrapping" real Java reflection classes in their instrumented versions wi l l work for other reflection classes, and thus fully support reflection under M o b i l e J . 4.7.5 j a v a . l a n g . C h a r a c t e r Class Initializer Dur ing development of M o b i l e J it was discovered that normal instrumentation of the static init ializer method of class j a v a . l a n g . C h a r a c t e r produced a method whose 64 bytecode was greater than 65535 bytes in length, larger than the max imum allowed in the class file format specification. A s a consequence, the J V M would refuse to run this method. The method is so large because this class contains three rather large private static arrays and all static data in Java is initialized through code in the class' static initializer; the more static da ta for a class, the larger the class init ializer. To work around this l imi ta t ion , the static init ial izer in the instrumented ver-sion of j a v a . l a n g . C h a r a c t e r is changed so that it s imply calls a method in the Mob i l e J Runt ime. If the method is run on the static host, it wraps a reference to the instance of each array in j a v a . l a n g . C h a r a c t e r 8 in an appropriate V A r r a y W r a p p e r instance and assigns this to the array field in u b c . m j . j a v a . l a n g . C h a r a c t e r . Thus the actual pr imit ive type data for these arrays is shared between the real and in-strumented versions of j a v a . l a n g . C h a r a c t e r ; this works because these arrays are only read from and not wri t ten to once ini t ial ized. If run on the non-static host, this method retrieves a reference to the field on the static host, i.e., a proxy object, and assigns it to the field on the non-static host. 4.7.6 j a v a . l a n g . R u n t i m e l o a d L i b r a r y M e t h o d To simplify the implementation, the instrumented version of the j a v a . l a n g . R u n t i m e . l o a d L i b r a r y method is turned into a null method which simply returns when called. Since applications which rely on native code won' t work with M o b i l e J anyways, this method does not need to be supported. Code in the instrumented versions of the standard Java libraries which calls this method 8Because they are private fields, these references can only be retrieved through use of a native method. 65 doesn't require it to do anything either, as al l native methods for these classes are contained in the M o b i l e J Nat ive Library , loaded when it starts up. 4.8 Creating Proxy Classes In addition to creating instrumented versions of class files, the Mob i l e J Instru-ment tool must create proxy classes corresponding to each instrumented class and ArrayWrapper subclass. The current implementat ion uses Voyager's vcc tool for creating proxy classes, but a custom tool could also be created i f Voyager were re-placed by a custom M o b i l e J Dis t r ibu t ion Layer . (See Section 6.2.2 on page 83 for discussion of replacing Voyager.) Proxies are created according to the following format: 9 • the class naming conventions described in Section 4.2.1 are followed, e.g., the proxy of class j ava. u t i l .Vector is named ubc.mj . java.ut i l .VVector. • the class hierarchy for proxy classes mirrors the class hierarchy of instrumented classes, e.g., since java.ut i l .Stack inherits from java.ut i l .Vector, the proxy class ubc .mj . java.ut i l .VStack inherits from ubc.mj.java.util.VVector. • a proxy class implements the same interfaces as the instrumented class it is a proxy for • the same exceptions thrown by methods, including constructors, in an instru-mented class are thrown by methods in its associated proxy class 9These specifications closely follow the format of Voyager "virtual classes" [Obj97, pages 46-47] because the current implementation of MobileJ uses Voyager as its Distribution Layer. 66 • for every instance method in the instrumented class, the proxy class contains an instance method of the same name, and wi th the same type signature • for every constructor in the instrumented class, the proxy class contains a constructor wi th the same type signature and an addit ional S t r i n g parameter, used to designate the M o b i l e J host and port number on which to construct an instance of the class • both static and instance fields, as well as static methods 1 0 do not have an equivalent in M o b i l e J proxy classes because fields are accessed through accessor methods, as discussed in Section 4.6, page 51 Since proxy classes form part of Mob i l e J ' s Dis t r ibu t ion Layer, a description of what functionality they must implement is found in Section 3.2, page 23. 4.9 Implementing Bytecode Instrumentation Creat ing a tool which instruments Java bytecode is challenging for a number of reasons; two issues in particular are described below. 4.9.1 Maintaining Flow Control Branch instructions in Java bytecode indicate branch targets using relative offsets; inserting or deleting instructions, as required by M o b i l e J , requires re-setting these offset values for instructions affected. To implement this, an I n s t r u c t i o n V e c t o r class was created which mod-elled method bytecode as a vector of instructions. A s wi th standard Java V e c t o r s , 10Voyager creates equivalent static methods when it creates its "virtual classes", but these are not used in the current implementation of MobileJ. 67 InstructionVectors can have individual elements (instructions) added, changed, or removed. They can also emit a version of the vector as an array of bytes, for inclusion in a class file. W h e n this final version of the method bytecode is requested, the InstructionVector re-sets al l relative offsets. The Instruct ionVector accomplishes this by maintaining a mapping be-tween original code position and new code position in the instruction vector. Thus all new relative offset values can be determined by looking up the equivalent old ab-solute offset, retrieving the new absolute offset, and deriving the new relative offset given the current instruction posit ion. However, if code is inserted before the target of a branch it is sometimes the intention of the instrumenting code to have the target be re-directed to the start of the newly inserted code. To handle this case, every map entry has a previous field, which is either null or references the previous instruction in the Instruct ionVector. W h e n inserting an instruct ion, instrumenting code can choose to have the previous field set for the instruction being inserted before. Th i s re-directs branch targets to the newly inserted instruct ion. Using this design also requires that, for a block of instructions being inserted, the instructions be inserted in reverse order of their execution in bytecode in order for the previous fields to be linked in a chain. Th i s ensures that the first instruction in the block wi l l become the new target of any branches originally intended for the instruction the block was inserted before. Bytecode offset values in a method's exception handler table are also changed according to the mapping maintained in the Instruct ionVector. 6 8 4.9.2 Debugging Support Due to the relative immatur i ty of Java in general, there do not exist many tools (especially freely available tools) for debugging Java bytecode. It would be much easier to debug a tool such as the Mob i l e J Instrument ut i l i ty if a debugger which could control Java execution at the bytecode level were available. M o s t available de-buggers, including Sun's j d b util i ty, are meant pr imari ly for source level debugging, and don't allow for much control at the bytecode level. To aid debugging of M o b i l e J an option to output method call t racing was added to the Mob i l e J Runt ime and Instrument tool . W h e n turned on, the Instru-ment tool inserts calls to methods in the M o b i l e J Runt ime at the start of each method and before any return instructions in the method. The M o b i l e J Runt ime methods output tracing information to a file, showing the stack depth and the method being entered or returned from, similar to what is output when Sun's im-plementation of the J V M is started wi th method tracing enabled.. (The trace output directly from the J V M was not useful because it traced not only instrumented meth-ods but also methods of classes in the M o b i l e J Dis t r ibu t ion Layer, making these traces difficult to understand.) T w o tools which were of great help when debugging Mobi l e J ' s instrumen-tat ion were a bytecode disassembler and assembler. Using the disassembler, the Java "assembly" version of instrumented bytecode code could be created, and thus edited by hand in a text editor. Th i s allowed one to insert code to print messages, including variable values, to the screen (or a file). The assembly code could then be run through the assembler to produce a debugging version of the original class file. Though tedious, this was often the only way to debug instrumented bytecode. How-ever, a debugger wi th good bytecode level support would remove the need to work 69 with bytecode disassemblers and assemblers when debugging instrumented code. 4.10 Summary In order to facilitate location transparent access to objects, class files are instru-mented such that nearly all objects manipulated by a Mob i l e J application are proxy objects. These proxy objects redirect all method invocations to the "real" objects which they represent, either on the local machine or a remote one. Th i s way, the M o -bileJ Runt ime can move objects at wi l l between machines without the application's knowledge. However, since both arrays and fields are handled directly by J V M instruc-tions, access to them is transformed into method invocations through proxy objects, allowing for location transparent access by the same mechanism used for explicit method invocation. The M o b i l e J Instrument tool processes class files, including bytecode in-structions. Whi l e it is possible to imagine a tool that could s imilar ly process other executable formats, the large amount of symbolic information present in class files makes a project such as this more feasible. The class file format and J V M require storage of symbolic information pr imari ly to support dynamic code l inking, but this design also allows for other applications, of which the Instrument tool is one example. (See Section 5.1, page 71 for other examples.) 70 Chapter 5 Related Research 5.1 J V M Class Instrumentation Tools A t least three other tools have been developed which allow instrumentat ion of J V M class files; these are described below. 5.1.1 Bytecode Instrumenting Tool (BIT) B I T , as described in [LZ97], is a toolki t for instrumenting Java bytecode. B I T was created as a tool to aid analysis of dynamic program execution behaviour. A s such, it provides the abil i ty to insert invocations of user-supplied static methods at part icular points in method bytecode, for example, at the beginning and end of a method or basic block, or after certain types of instructions. Th is type of instrumentat ion is very useful for implementing various forms of code profiling, but B I T could not be used as a tool to implement the instrumentat ion needed for M o b i l e J because it does not support changing of the J V M class file structure, references to constant pool entries, or insertion of arbi trary instructions. B I T is meant to be used in situations 71 where the semantic behaviour of an instrumented program is preserved. 5.1.2 J a v a O b j e c t I n s t r u m e n t a t i o n E n v i r o n m e n t ( J O I E ) The J O I E system, as described in [CC98], is a tool for J V M class file instrumentat ion which can perform load-time transformation of class files. J O I E is implemented as a Java class loader instance, and all instrumentat ion is performed at class load time, before the J V M begins interpreting any bytecode of the class. Users of J O I E cre-ate transformers, Java classes implementing the interface j o i e . C l a s s T r a n s f o r m e r which operate on class files when called upon by the J O I E class loader. The capabilities of J O I E are more extensive than those of B I T , al lowing for changes to every aspect of class file structure and bytecode instructions. J O I E even allows for changes to a method's frame, or local variable storage area, by adding and removing method parameters and local variables. It also deals wi th resetting of rel-ative branch targets and exception handler ranges (as does the Mob i l e J Instrument ut i l i ty) . J O I E could be used to implement the instrumentation required by M o b i l e J , however, doing so would require a high overhead (for instrumentation) each t ime a Mob i l e J application was run, without providing many inherent advantages. The extensive changes required of class files for use wi th M o b i l e J makes static instru-mentation the best opt ion. 5.1.3 B i n a r y C o m p o n e n t A d a p t a t i o n A prototype B ina ry Component Adap ta t ion ( B C A ) system for J V M class files is described in [KH.98]. Th i s B C A system works very similarly to J O I E , transforming class files at load t ime. However, the B C A system uses delta files and associated delta 72 file compiler instead of transformer classes to customize the code transformation. De l t a files describe the types of transformations required (using a specific syntax) which the compiler converts to J V M class files for loading and invocation by the B C A ' s custom class loader. Th i s B C A system does not appear to support adding or removing arbi t rary bytecodes from a method, therefore it would not be suitable for implementing the type of bytecode instrumentation required by M o b i l e J . B C A is intended to support less comprehensive modifications to class files than those required by M o b i l e J . 5 .2 Systems Supporting Mobile Applications M a n y systems have been developed to assist application developers in creating pro-grams for the mobile computing environment. Some are implemented purely at the t radi t ional operating system level, while others are frameworks for building part i -tioned applications. A s described in Section 1.2.2 (page 5), systems can be classified based on whether they implement a static or dynamic application part i t ion, and to what extent the system attempts to hide the constraints of the mobile computing envi-ronment from the application; a sampling of systems are described below. 5.2.1 S ta t ica l ly Par t i t ioned Systems Mobile-Aware Systems Odyssey [Nob98, NSN+97 , NPS95] is a system support ing mobile information ac-cess, created at Carnegie Mel lon University. Specifically, it is an extension of the N e t B S D (Unix) file system support ing file access from mobile computers. T h e 73 Odyssey project examines issues such as consistency of mobile data, coordinated management of resources on a mobile host, and application agility, or, the abi l i ty of the application to adapt to changes in resource availability. Whi l e the system allocates resources and monitors their availability, it assumes each application pro-vides functionality for adapting to changes in resource constraints. Odyssey notifies applications when resource constraints change, for example, when the available net-work bandwidth decreases. Thus applications cooperate wi th the operating system in adapting to the varying mobile environment, and makes Odyssey applications mobile-aware. Another stat ically part i t ioned, mobile-aware architecture is presented by Well ing and Badr ina th in [WB98, W B 9 7 ] . Th i s system focusses on providing an appropriate framework for delivering environment related events to applications ex-ecuting on mobile computers. A s wi th Odyssey, events associated wi th changes in resource availability are delivered to applications using this framework, where they are handled in an application specific way. Whi l e not explici t ly required by their implementation, Wel l ing and B a d r i -nath suggest isolating the modules which implement an application's environmental adaptat ion policies, and avoid incorporat ing adaptat ion code in all modules, re-sult ing in a form of "spaghetti code". They note that not only does this result in a more maintainable applicat ion, but also that it eases reengineering of existing applications to support functioning in a mobile environment. Prototypes of this architecture have been implemented in M a c h 3.0 and Java [WB98] . 74 Mobile-Transparent Systems Stat ical ly part i t ioned, mobile-transparent systems are most easily implemented at either some layer of the user-interface, or at the filesystem or network access oper-ating system interface, corresponding wi th the left and right extremes, respectively, of Figure 1.1 (page 6). Implementations of the X - W i n d o w s protocol have been adapted to function in the low-bandwidth, high-latency environment typical of wireless networks. However, the X - W i n d o w s network protocol and architecture were noted in [KDF+93] as being part icularly difficult to adapt to a wireless environment because of the bandwidth and latency constraints: they concluded by remarking, "We are not at all convinced that using X for pen-based mobile/wireless computing is a good idea." Further work, described in [Dan94], shows a compression ratio of 7.5:1 is possible for the X - W i n d o w s protocol, yielding, for example, a six second transfer time when viewing a text document wi th Ghostv iew. The author notes that this is likely to improve as the compression is tuned, however, it remains that the X -Windows protocol was designed in the context of relatively high-bandwidth, low-latency Ethernet networks. Highly interactive applications, especially those wi th graphical user interfaces are unlikely to achieve acceptable performance using X over wireless networks. Implemented at a slightly different layer of the user-interface, the V i r t u a l Network Compute r system [WRB+97 , R S F W H 9 8 ] operates by t ransmit t ing an en-coded version of a user's screen from a server to a thin client (the Java client is a 2 0 K b applet). The system is intended to promote access to a user's "home comput-ing environment" from a variety of comput ing devices. T w o l imitat ions of the V N C system appear to be client computat ional power, 75 and available network bandwidth and latency-basically the same problems noted when using X - W i n d o w s over poor links, although a client is currently being devel-oped for the 3 C O M P a l m P i lo t , connected by a wireless modem [Min98]. Whi l e V N C may be appropriate for use by mobile users wi th access to many wirelessly connected workstations in the same metropoli tan area, it does not appear workable when the bandwidth and latency restrictions of the network being used approach those of wireless networks. Systems which function at the filesystem and network O S interface include the Mobi le Appl ica t ion Framework ( M A F ) described in [HR97], and the Advanced Mobi l e Integration in General Operat ing Systems ( A M I G O S ) project [ H R A J 9 8 , H R 9 6 , G M 9 5 ] . For network communicat ion, M A F optimizes T C P network connec-tions by replacing recognized application level protocols, for example "ftp", wi th an optimized data transfer protocol over the wireless portion of a T C P connection. The A M I G O S "Spli t -Connect ion T C P " design [ H R A J 9 8 , HR96] allows for transparent changing of the link-layer connection without disconnection of the T C P layer con-nection. Therefore a mobile host can move between a wireless network and a wired L A N without disrupt ing active T C P connections. 5.2.2 Dynamically Partitioned Systems Mobile-Aware Systems W i t [Wat94b, Wat94a, Wat95] was one of the earliest systems designed to support mobile applications through part i t ioning an application between a small , mobile client and server. The W i t system provides a T e l interpreter on both the mobile host ( H P 1 0 0 L X palmtops running D O S 5.0) and proxy server host. The W i t A P I provides for remote execution of T e l scripts from both the mobile unit and proxy 76 applicat ion, thus allowing dynamic part i t ioning though runtime decisions about where a procedure should execute, but the intention seems to be to have most application functionality be statically part i t ioned. In [Wat95], a scheme for describing application data in terms of hyperobjects is presented; data, for example, world-wide-web pages, could be presented to the system as a set of hierarchically linked hyperobjects. The system would use this structure to make decisions about which parts of data requested at the mobile host to transfer, and also which to prefetch. Similar to W i t , Rover [ J T K 9 7 , J K 9 6 , Tau96, JdT+95] is an application de-velopment framework designed wi th the constraints of the mobile comput ing envi-ronment in mind . A s wi th W i t , designing a Rover application, or port ing an appli-cation to use Rover, involves spl i t t ing application functionality between the mobile and fixed hosts, and defining application da ta in terms of relocatable data objects ( R D O s ) which can be passed between the mobile and fixed hosts. The two halves of the program communicate v i a a queued remote procedure call protocol, which pro-vides for queuing and logging of asynchronous R P C requests while the mobile host is disconnected, and flushing of the log to the fixed host upon re-connection. A p -plications can decide where their various R D O s should be placed (at the mobile or fixed host) and when they should be moved, however, it appears that the part i t ion between mobile and fixed host is intended to be fairly static for most applications. Sumat ra [ARS97 , R A S S 9 7 , R A S 9 6 ] is a distr ibuted object system based on Java designed for building resource-aware applications. Sumatra extends Java wi th the abi l i ty to group objects, move object groups between hosts, create threads on remote hosts, and migrate threads between hosts. These capabilities are coupled wi th a distributed resource monitor which allows applications to be notified regard-77 ing resource constraints such as network latency and bandwidth, and host C P U load (although the most recently described implementation monitors only network latency). Al though its developers do not appear to have targeted applications de-ployed to mobile computers, applications built wi th Sumat ra have the abi l i ty to adapt to changes in their computat ional environment through moving parts of (or all of) the application to different hosts, for example, to minimize latency between hosts for some interaction. The designers describe an Internet chat server which can migrate between hosts based on the latency observed between it and client hosts, in an at tempt to optimize its location for all users. Mobile-Transparent Systems M - M a i l [Lo97, L K 9 6 ] , an email system designed for use in the mobile environment, serves as a case study on dynamic, mobile-transparent application par t i t ioning. M -M a i l uses the Men ta t P rogramming Language ( M P L ) , a language based on C + + , and the Menta t Run -T ime System ( M R T S ) for distributed object creation and in-vocat ion. M - M a i l also makes use of a specific A P I [NKB96] for moni tor ing network conditions (e.g., bandwidth, latency, error rate) at run time. The M P L and M R T S support creation of large grained objects, each created as a separate U n i x process. M - M a i l creates a separate Menta t object for each folder of email messages a user has. The objective of the M - M a i l project was to derive an appropriate object placement a lgori thm based on run t ime network conditions. A s the M R T S does not have support for object migrat ion, al l placement decisions are made at object creation t ime (when the M - M a i l application starts up), however, a history of the number and frequency of object invocations for each object (i.e., email folder) is recorded and stored between executions of M - M a i l . 78 Al though M - M a i l is one of few studies concentrating on deriving appropriate object placement policies for the mobile computing environment, it is difficult to see how the large grained objects used in the M R T S can be used to compose other applications. Further study is also needed to determine appropriate algorithms for use when object migration is available. Though not designed for use specifically in a mobile-computing environment, Coign [HS98b, HS98a, HS97] is an implementation of application part i t ioning for Microsoft C O M based applications. Like M o b i l e J , Coign combines application bi-nary instrumentation wi th runtime dis tr ibut ion control, to produce a system which can part i t ion an application without access to application source code. Using Coign involves instrumenting an application binary, adding profiling code which records al l C O M component instantiations and inter-component func-tion calls. The application is then run (on a single machine) through any number of profiling scenarios, where information is collected by the instrumented version of the applicat ion. After the profiling scenarios have been run, a separate application anal-yses the collected profiling data, and determines an op t imum configuration based on the number of bytes transferred between components, the number of machines in the distr ibuted system, and possibly other factors, such as network condit ion between hosts. The analysis involves creating a connected graph consisting of component instances as vertices and inter-component communicat ion cost as edges, and cut t ing the graph so as to minimize communicat ion between machines. For a client-server configuration, the analysis takes into account that certain components (e.g., G U I controls) must always be placed on the client. The application is then run, wi th the Coign runtime system instantiat ing a distributed configuration of the applicat ion, based on the results of the graph par t i t ioning analysis. 79 The most difficult task for the Coign runtime during distr ibuted execution is matching component instantiations wi th those recorded during profiling, in order to achieve the op t imum distr ibut ion found during analysis. Since Co ign separates profiling execution from distr ibuted execution, i f the distr ibuted execution varies too greatly from the scenario profiled, Coign wi l l not be able to achieve an op t imum dis t r ibut ion. The advantage of this design, however, is that the runtime system has to do less work during distr ibuted execution, exacting only a 3% overhead during these executions [HS98a]. The use of static profiling also means that Coign is unable to migrate component instances once created; all configuration decisions are made statically, at analysis t ime. 80 Chapter 6 Conclusions 6.1 Summary The M o b i l e J system is designed to support dynamic part i t ioning of J V M appli-cations between a smaller, less powerful mobile host and a larger, more powerful stat ionary host. B y using class file (object code) instrumentation, M o b i l e J hides the details of part i t ioning from the application programmer, making the system mobile-transparent. The Mob i l e J system consists of an Instrument tool and Runt ime, including a native library. The Instrument tool transforms class files such that their bytecode manipulates "proxy" objects instead of "real" objects. M e t h o d invocations are made to go through these proxy objects, which redirect them to the application objects they represent. In this way, application objects may be placed on either the mobile host or the stationary host under runtime control , their location being transparent to the instrumented application code. The M o b i l e J Runt ime handles application startup, and is responsible for 81 maintaining a part i t ioning policy. Whi l e the current implementation parti t ions ap-plications based on object type only, creating a static par t i t ion, the Runt ime may be extended by adding an object placement policy module. Th i s module would maintain references to al l application objects and make decisions on where objects should be placed and under what circumstances. It is intended that M o b i l e J serve as a basis for experimentation and further research into object placement policies for mobile applications. Whi l e Mob i l e J pro-vides the mechanism for dynamic part i t ioning of applications, it is st i l l unclear how to best part i t ion applications in the mobile environment. 6.2 Future Work A s wi th most systems research projects, there is much that could be done to extend the work presented here. Th i s section describes a number of possible extensions for future work. 6.2.1 Po r t i ng A W T Na t ive Me thods The current implementation of M o b i l e J does not support running Java applications ut i l izing a graphical user interface ( G U I ) , unfortunately perhaps the majori ty of applications wri t ten wi th Java. To do so, the native methods implementing Java A W T "peers" need to be ported to work with M o b i l e J . Th i s is necessary because the native methods manipulate objects, and are not expecting proxy objects to be passed as parameters. Th i s task is more tedious than it is difficult, as all method invocations and field accesses from native code must be changed such that they work wi th the rest of M o b i l e J , i.e., they access proxy objects instead of "real" objects. The Instrument 82 tool only processes Java bytecode; native method code must be changed "by hand" . Por t ing the A W T to work wi th M o b i l e J would allow most Java applications to be run under M o b i l e J . 6.2.2 M o r e Efficient D i s t r i bu t i on Layer The performance of Mob i l e J is pr imari ly dependent on the efficiency of the M o b i l e J Dis t r ibu t ion Layer (see Section 3.2). The current implementation, ut i l iz ing Voyager [Obj97], is not very efficient because Voyager is not optimized for local method invo-cations. A new implementation, built specifically with the requirements of Mob i l e J in mind and optimized for local invocations, could perform much better. 6.2.3 D y n a m i c M o n i t o r i n g and Object Placement P o l i c y Modu le s M o b i l e J currently lacks modules to monitor the computat ional environment and object interactions, and an object placement policy module. The environment mon-i tor ing module would watch such environmental factors as C P U load and available network bandwidth and latency, providing an indication of the current computa-t ional and network environment to the policy module (as in the M - M a i l system described in Section 5.2.2, page 76). The object interaction module would keep track of the frequency of interaction as well as the amount of da ta transferred be-tween objects, also providing this data to the object placement policy module. The object placement policy module would combine da ta from the two mon-i toring modules to optimize object placement for a running appl icat ion. The policy module would work similarly to Coign ' s analysis program (see Section 5.2.2), creat-ing a connected graph of objects in the applicat ion, except that the complete graph would be distributed between the mobile client and fixed server and would be up-83 dated continuously while the application is running. Ideally the placement policy could be configured by describing a relative weighting between environmental fac-tors and object characteristics (size, invocation frequency and bandwidth) in order to facilitate experimentation wi th different applications and policies. 6.2.4 Study of Appl ica t ions and Object Placement Policies Given the modules described in the previous section, a study of a variety of applica-tions and object placement policies would be enlightening. Whi l e similar in flavour to the M - M a i l study [Lo97], such an investigation would show where different types of applications should be parti t ioned and under what circumstances. It might also attempt to determine which factors should have the greatest influence on object placement policies, and derive a well-performing object placement a lgori thm. If mobile computers are to become more ubiquitous, a greater understanding of how particular types of applications should be built for use in this environment needs to be achieved. 6.3 Final Conclusions The Mob i l e J system provides a basis for further investigation of dynamic, mobile-transparent application par t i t ioning for the mobile environment. Whi l e the benefits of having completely transparent, runtime controlled object placement for mobile applications remains to be verified, Mob i l e J is a step in this direction. It is hoped that further investigations may reveal the extent to which runtime systems can adapt to changes in the mobile environment through dynamical ly monitor ing application behaviour. 84 Bibl iography [ARS97] A n u r a g Acharya , M . Ranganathan, and Joel Saltz. Sumatra : A Language for Resource-aware Mob i l e Programs. In J . V i t e k and C . Tschudin, editors, Mobile Object Systems, volume 1222 of Lecture Notes in Computer Science. Springer Verlag, 1997. h t t p : / / w w w . cs .umd.edu/~acha/papers / lncs97- l . h tml . [Bha97] Vaduvur Bharghavan. Challenges and Solutions to Adap t ive Compu t ing and Seamless M o b i l i t y over Het-erogeneous Wireless Networks. International Jour-nal on Wireless Personal Communications, M a r c h 1997. h t tp : / / t imely .c rhc .u iuc .edu/Papers /Abs t rac t s /CS_abs t rac t .h tml . [CC98] Geoff A . Cohen and Jeffrey S. Chase. Au toma t i c Program Transfor-mation wi th J O I E . In Proceedings of the USENIX Annual Technical Conference, New Orleans, L A , U S A , June 1998. [Dan94] John Moffat t Dansk in . Compressing the X Graphics Protocol. P h D thesis, Pr inceton Universi ty, November 1994. [Dea98] A l a n Dearie. Toward Ubiqui tous Environments for Mob i l e Users. IEEE Internet Computing, 2 ( l ) :22-32 , Jan-Feb 1998. [Duc92] D a n Duchamp. Issues in Wireless Mob i l e Comput ing . In Proceedings of the Third IEEE Workshop on Workstation Operating Systems, pages 2-10, A p r i l 1992. [DWJ+96] Tzvetan T . Drashansky, Sanjiva Weerawarana, A n u p a m Joshi , R a n -jeewa A . Weerasinghe, and El ias N . Houstis . Software Archi tecture of Ubiqui tous Scientific C o m p u t i n g Environments for Mob i l e Pla t forms. ACM Mobile Networks and Applications, 1(4), 1996. [Fla97] D a v i d Flanagan. Java in a Nutshell. O 'Re i l l y and Associates, Se-bastopol, C A , U S A , 2nd edition, M a y 1997. 85 [FZ94] George H . Forman and John Zahorjan. The Challenges of Mobi le C o m -puting. Technical Report U W - C S E - 9 3 - 1 1 - 0 3 , Department of Computer Science and Engineering, Universi ty of Washington, Seattle, W A , U S A , M a r c h 1994. [GJS96] James Gosl ing, B i l l Joy, and G u y Steele. The Java Language Specifi-cation. Addison-Wesley, Reading, M A , U S A , 1996. [GM95] V i t o r Guedes and Francisco M o u r a . Repl ica Con t ro l in M I o - N F S . In Proceedings of the ECOOP 1995 Workshop on Mobility and Replica-tion, Aarhus , Denmark , August 1995. [HR96] J0rgen Svaerke Hansen and Torben Reich . Semi-Connected T C P / I P in a Mobi le C o m p u t i n g Environment . Master ' s thesis, Department of Computer Science, Univers i ty of Copenhagen, Copenhagen, Denmark, June 1996. [HR97] Stefan G . H i l d and Peter Robinson. Mob i l i z ing Appl ica t ions . IEEE Personal Communications, 4(5):26-34, October 1997. [ H R A J 9 8 ] J0rgen Svaerke Hansen, Torben Reich, Birger Andersen, and E r i c J u l . Dynamic Adap ta t ion of Network Connections in Mobi le Environments . IEEE Internet Computing, 2(1), Jan-Feb 1998. [HS97] Galen C . Hunt and Michae l L . Scott . Co ign : Efficient Instrumentation for Inter-Component Communica t ion Analys i s . Technical Report 648, Department of Computer Science, Universi ty of Rochester, Rochester, N Y , U S A , February 1997. [HS98a] Galen C . Hunt and Michae l L . Scott . A Guided T o u r of the Coign Au tomat i c Dis t r ibuted Par t i t ion ing System. Technical Report M S R -TR-98-32, Microsoft Research, Microsoft Corpora t ion , Redmond, W A , U S A , Ju ly 1998. [HS98b] Galen C . Hunt and Michae l L . Scott . The Coign A u t o m a t i c Dis t r ibuted Par t i t ioning System. Technical Report M S R - T R - 9 8 - 4 0 , Microsoft Re-search, Microsoft Corpora t ion , Redmond, W A , U S A , Augus t 1998. [ J d T + 9 5 ] Anthony D . Joseph, A l a n F . deLespinasse, Joshua A . Tauber, D a v i d K . Gifford, and M . Frans Kaashoek. Rover: A Too lk i t for Mob i l e Informa-tion Access. In Proceedings of the 15th ACM Symposium on Operating System Principles, Copper Moun ta in Resort, Colorado, U S A , Decem-ber 1995. 86 [JK96] An thony D . Joseph and M . Frans Kaashoek. Bui ld ing Reliable Mobi le -Aware Appl ica t ions using the Rover Too lk i t . In Proceedings of the Second ACM International Conference on Mobile Computing and Net-working, November 1996. [ JTK97] An thony D . Joseph, Joshua A . Tauber, and M . Frans Kaashoek. Mob i l e Compu t ing with the Rover Too lk i t . IEEE Transactions on Computers, 46(3), M a r c h 1997. [Kat94] Randy H . K a t z . Adap ta t ion and M o b i l i t y in Wireless Information Systems. IEEE Personal Communications, 1(1):6-17, 1994. [ K D F + 9 3 ] Chris topher Kent Kantar j iev, A l a n Demers, Ron Frederick, Rober t T . Kr ivac ic , and M a r k Weiser. Experiences wi th X in a Wireless E n -vironment. In Proceedings of the USENIX Mobile and Location-Independent Computing Symposium, Cambridge, Massachusetts, U S A , August 1993. [KH98] Ra lph Keller and Urs Holzle . B ina ry Component Adap ta t ion . In Pro-ceedings of the 12th European Conference on Object-Oriented Program-ming, Brussels, Be lg ium, Ju ly 1998. [LK96] H a i Y a n L o and Thomas K u n z . A Case Study of D y n a m i c Appl i ca t ion Par t i t ion ing in Mob i l e C o m p u t i n g - A n E-ma i l Browser. In Proceed-ings of the Workshop on Object Replication and Mobile Computing of OOPSLA 1996, San Jose, C A , U S A , October 1996. [Lo97] H a i Y a n L o . M - M a i l : A Case Study of Dynamic Appl i ca t ion Par t i t ion-ing in Mobi le Compu t ing . Master ' s thesis, Department of Compute r Science, Universi ty of Water loo, Waterloo, O N , Canada , 1997. [LZ97] Han Bok Lee and Benjamin G . Zorn . B I T : A T o o l for Instrumenting Java Bytecodes. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Monterey, C A , U S A , December 1997. [MD97] Jon Meyer and Troy Downing . Java Virtual Machine. O ' R e i l l y and Associates, Sebastopol, C A , U S A , 1997. [MDC93] Br i an M a r s h , Fred Douglis , and R a m o n Caceres. Systems Issues in Mobi le Comput ing . Technical Report M I T L - T R - 5 0 - 9 3 , Ma t sush i t a Information Technology Laboratory, Princeton, N J , U S A , February 1993. 87 [Min98] V l a d i m i r Minenko . V i r t u a l Network Compu t -ing Client for P a l m Pla t form, September 1998. h t tp : / /www.ics i .berke ley .edu/~minenko/Palm V N C . [NKB96] Michae l N i d d , Thomas K u n z , and James P. Black . Wireless A p p l i c a -t ion and A P I Design. In Proceedings of the Fourth International IFIP Workshop on Quality of Service, Paris , France, M a r c h 1996. [Nob98] B r i a n D . Noble. Mobile Data Access. P h D thesis, School of Compute r Science, Carnegie Mel lon Universi ty, P i t t sburg , P A , U S A , M a y 1998. Avai lable as technical report C M U - C S - 9 8 - 1 1 8 . [NPS95] B r i a n D . Noble, M o r g a n Pr ice , and M . Satyanarayanan. A Program-ming Interface for Appl ica t ion-Aware Adap ta t ion in Mob i l e Compu t -ing. In Proceedings of the Second USENIX Symposium on Mobile and Location-Independent Computing, A n n A r b o r , M I , U S A , A p r i l 1995. [ N S N + 9 7 ] B r i a n D . Noble, M . Satyanarayanan, Dushyanth Narayanan, James Er i c T i l t o n , Jason F l i n n , and K e v i n R . Walker . Agi le Appl ica t ion-Aware Adap ta t ion for Mob i l i t y . In Proceedings of the 16th ACM Symposium on Operating System Principles, St. M a l o , France, October 1997. [Obj97] ObjectSpace, Inc. Voyager Core Technology User Guide. ObjectSpace, Inc., 1.0.0 edition, 1997. [RAS96] M . Ranganathan, A n u r a g Acha rya , and Joel Sal tz . Dis t r ibuted Re-source Moni to r s for Mob i l e Objects . In Proceedings of the Fifth IEEE International Workshop on Object-Orientation in Operating Systems, Seattle, W A , U S A , October 1996. [RASS97] M . Ranganathan, A n u r a g A c h a r y a , Shamik D . Sharma, and Joel Sal tz . Network-aware Mobi le Programs. In Proceedings of the USENIX An-nual Technical Conference, Anahe im, C A , U S A , January 1997. [ R S F W H 9 8 ] Tr is tan Richardson, Quentin Stafford-Fraser, Kenneth R . W o o d , and A n d y Hopper. V i r t u a l Network Compu t ing . IEEE Internet Comput-ing, 2 ( l ) :33-38 , Jan-Feb 1998. [RWW96] Roger Riggs, J i m Waldo , and A n n Wol l r a th . P ick l ing State in the Java System. In Proceedings of the USENIX 1996 Conference on Object-Oriented Technologies, Toronto, O N , Canada , June 1996. 88 [Sat93] M . Satyanarayanan. Mob i l e Comput ing . IEEE Computer, 26(9), September 1993. [Sat96] M . Satyanarayanan. Fundamental Challenges in Mob i l e Compu t ing . In Proceedings of the 15th ACM Symposium on the Principles of Dis-tributed Computing, Phi ladelphia , P A , U S A , M a y 1996. [Sun97] Sun Microsystems, Inc. Java Native Interface Specification, Release 1.1. Sun Microsystems, Inc., Moun ta in View, C A , U S A , M a y 1997. [Tau96] Joshua A . Tauber. Issues in Bu i ld ing Mobi le -Aware Appl ica t ions wi th the Rover Too lk i t . Master ' s thesis, Department of Electr ical E n g i -neering and Computer Science, Massachusetts Institute of Technology, June 1996. [Wat94a] Terr i Watson. App l i ca t ion Design for Wireless Compu t ing . In Pro-ceedings of the IEEE Workshop on Mobile Computing Systems and Applications, Santa C r u z , C A , U S A , December 1994. [Wat94b] Terr i Watson. W i t : A n Infrastructure for Wireless Pa lmtop Comput -ing. Technical Report U W - C S E - 9 4 - 1 1 - 0 8 , Department of Computer Science and Engineering, Univers i ty of Washington, Seattle, W A , U S A , November 1994. [Wat95] Terr i Watson. Effective Wireless Communica t ion Through Appl i ca t ion Par t i t ion ing . In Proceedings of the Fifth Workshop on Not Topics in Operating Systems, Orcas Island, W A , U S A , M a y 1995. [WB97] Gi r i sh Well ing and B . R . Badr ina th . A Framework for Environment Aware Mobi le Appl ica t ions . In Proceedings of the 17th International Conference on Distributed Computing Systems, pages 384-391, B a l t i -more, M D , U S A , M a y 1997. [WB98] Gi r i sh Well ing and B . R . Badr ina th . A n Archi tecture for Expo r t i ng Environment Awareness to Mob i l e Compu t ing Appl ica t ions . IEEE Transactions on Software Engineering, 24(5):391-400, M a y 1998. [WRB+97] Kenneth R . W o o d , Tris tan Richardson, Frazer Bennet, A n d y Harter , and A n d y Hopper . G l o b a l Teleporting with Java: Toward Ub iqu i -tous Personalized Compu t ing . IEEE Computer, 30(2):53-59, February 1997. 89 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051662/manifest

Comment

Related Items