Application Partitioning - A Dynamic, Runtime, Object-level Approach

Transcription

1 Application Partitionin - A Dynamic, Runtime, Object-level Approach Dissertation submitted in partial fulllment of the requirements for the deree of Master of Technoloy by Anshu Veda (Roll no ) under the uidance of Prof. Sridhar Iyer Kanwal Rekhi School of Information Technoloy Indian Institute of Technoloy Bombay 2006

2

3 Dissertation Approval Sheet This is to certify that the dissertation entitled Application Partitionin - A Dynamic, Runtime, Object-level Approach by Anshu Veda (Roll no ) is approved for the deree of Master of Technoloy. Prof. Sridhar Iyer (Supervisor) Prof. Anirudha Sahoo (Internal Examiner) Prof. Om Damani (Internal Examiner) Prof. Varsha Apte (Chairperson) Date: Place: i

4

5 INDIAN INSTITUTE OF TECHNOLOGY BOMBAY CERTIFICATE OF COURSE WORK This is to certify that Ms. Anshu Veda was admitted to the candidacy of the M.Tech. Deree and has successfully completed all the courses required for the M.Tech. Proramme. The details of the course work done are iven below. Sr.No. Course No. Course Name Credits Semester 1 (Jul { Nov 2004) 1. IT601 Mobile Computin 6 2. HS699 Communication and Presentation Skills (P/NP) 4 3. IT603 Data Base Manaement Systems 6 4. IT619 IT Foundation Laboratory IT623 Foundation course of IT - Part II 6 6. IT694 Seminar 4 Semester 2 (Jan { Apr 2005) 7. CS686 Object Oriented Systems 6 8. EE701 Introduction to MEMS (Institute Elective) 6 9. IT630 Distributed Alorithms IT608 Dataminin and Data Warehousin IT680 Systems Lab. 6 Semester 3 (Jul { Nov 2005) 12. CS601 Alorithms and Complexity (Audit) CS681 Performance Evaluation of Computer Systems and Networks 6 Semester 4 (Jan { Apr 2006) 14. CS705 Web Search and Minin (Audit) 6 M.Tech. Project 15. IT696 M.Tech. Project Stae - I (Jul 2005) IT697 M.Tech. Project Stae - II (Jan 2006) IT698 M.Tech. Project Stae - III (Jul 2006) 42 I.I.T. Bombay Dated: Dy. Reistrar(Academic) v

6

7 Abstract With the advent of increase in the computational complexity of the prorams, it seems conducive to distribute a centralized proram written for a standalone system onto a network of nodes. Application partitionin is one such technique, that aims at division (allocation) of application components amonst dierent hosts in the network, thereby ettin a standalone application executed in a distributed settin. Most of the existin work in application partitionin, uses classes as the basic component for partitionin. However, the behavior of an application is determined by the interaction of its entities at run-time. In an object-oriented proram, the run-time entities are principally objects. We believe that, a more eective and relevant partitionin mechanism can be created by considerin objects as the basic components for distribution. We also believe that, a truly exible partitionin system should as far as possible, postpone the decision reardin the placement of each component to run-time. Any such decision should try to optimize on both - the number of remote invocations that a distribution stratey would result in, as well as the load distribution on the available hosts. We thus propose a workin architecture that exploits the dependency relationships between the components, to build a model prior to the proram execution. At run-time, the model proressively incorporates the information about already allocated components and helps in decidin the position of new component.

8

9 Contents Abstract List of ures i v 1 Introduction Application Partitionin Motivation Problem Statement Thesis Outline Related Work Introduction Existin Middleware Technoloies Distribution Infrastructures Issues Related with RMI Distribution Infrastructures as backends Doorastha Partitionin Schemes Features of a Partitionin Scheme Addistant and J-Orchestra Panaea Coin Application Partitionin - A Taxonomy Object-level Partitionin - Architecture and Desin Introduction and Motivation Architecture for Object Level Partitionin An example Dependency Analyzer Sinicance of initial placement Statistical Approach to O-L Partitionin Bayesian Belief Networks - Applicability iii

10 iv Contents Dependency Model Translator Run-time Analyzer and Query Enine Object allocation decision Functionin of Run-time Analyzer Run-time System Comparison with the Related Work Implementation Details Standalone Prolin Codin the object model - BBN Run-time Issues Extensions to the current Implementation Code Translation and Instrumentation for Run-time Conclusion and Future Work 35 Biblioraphy 37 Appendix 39 A Example 39 B Instrumentation and Prolin 42 B.1 Tracker Class B.2 Prolin Implementation B.3 Prolin Output B.3.1 Object Information Table B.3.2 Dependency Matrix B.4 Model C Example - Translated Code 51 C.1 Supportin Proxy class C.2 Supportin Wrapper class C.3 Instrumented CarModel class

11 List of Fiures 1.1 Standalone vs Distributed Application Proxy-Based Approach-Transparent handlin of remote and local references Panaea - Object Graph Application Partitionin Taxonomy Class vs Object Level Partitionin System Overview An Example Dependency Analyzer BBN - An Example network Runtime-Analyzer Illustration of the runtime Prolin Flow BBN Generator An example vistor pattern B.1 Taed object information extract B.2 Dependency Matrix B.3 Dependency Matrix v

12

13 Chapter 1 Introduction Distributed computin has emered as an inevitable need in the modern world of larescale systems and hih power networks. Since quite a lon while however, the emphasis has been on client-server prorams and to an extent, concurrent prorams intended for parallel prorammin. In current-day scenarios where there are multiple complex applications, deployed on a network of multiple nodes usin widely distributed resources, distributed execution is hihly useful. However, codin such an application is not so easy. Prorammin lanuaes like C/C++, Java provide RPC 1 -based RMI 2, CORBA and like techniques. However, these techniques do not provide enouh transparency to the prrammer. It is thus desirable to have a system which not only automatically distributes a standalone application, adaptin to varyin distribution settins, but also provides the advantaes of distributed computin. 1.1 Application Partitionin Application partitionin refers to, breakin up of the application into components while preservin the semantics of oriinal application. The source application miht be desined, implemented and debued to run on a standalone system. The resultin components however, are distributed so as to take advantae of distributed settin. 1.2 Motivation Partitionin of Object-Oriented prorams is motivated by the followin reasons : Distribution of proram components Considerin the scenario of multiple lare-scale, multi-user, heteroeneous applications usin a wide variety of resources in a network. Code for a standalone system based application, as shown in Fiure 1.1 would be monolithic, functionin at some 1 Remote Procedure Call 2 Remote Method Invocation-The object oriented counterpart 1

14 Motivation central node makin expensive network calls. A distributed application would however, have components (framents) distributed all over the network 1.1, reducin amount of remote communication overhead, thereby optimizin the proram execution. Fiure 1.1: Standalone vs Distributed Application For illustration, consider a lare bankin application, which has its databases distributed over eoraphically separated areas. A standalone code would be performin all the computations at the server end and make expensive network calls, whereas a distributed application can have computations dispersed accordin to resource distribution. In addition, idle hosts can share the load of a busy system by hostin a few components. With the increase in the computational complexity of the prorams, as well increase in number of network resources, it makes sense to have a tool that could distribute a centralized proram written for a standalone system on to a network of nodes. Such an idea comes with the natural advantaes of distributed computin - load reduction, resource sharin and to an extent improvement in concurrent execution. Thus, assumin the presence of an underlyin reliable, hih-speed computer network, on one hand when we would like to have distributed components of a sinle proram runnin at dierent computer nodes, at the same time we do not want prorammers to worry about the distribution aspects while codin. In other words, we would like to separate the distribution concerns from application loic. Abstraction over the middleware Java, C# provide Remote Method Invocation (RMI), CORBA and like mechanisms, for developin remotely invocable components. However, these middleware technoloies are complicated to code. They have special codin constructs, and pro-

15 1.3. Problem Statement 3 rammer has to think about the deployment scenario while desinin the classes. Java RMI for example, needs each remote class to be specially dened to extend a special interface. Creatin a remote object and ettin its access on remote node is a tedious job. Abstraction over deployment scenarios Primarily been desined to cater to client-server systems, current middleware technoloies also fail to provide enouh abstraction. The prorammer has to think and consider the distribution aspects while desinin the application. Finally, these constraints prevent the proram to be re-deployed eciently in dierent distributed settins.the above aruments justify the need of an automatic partitionin system, that optimally partitions source application written for a standalone system. In other words, a system that helps separate distribution concerns from application loic. We have studied and classied existin partitionin mechanisms, identied their limitations and subsequently desined a workin architecture which provides enouh exibility even at run-time to distribute components(objects). We have desined a Decision analyzer which aims at placin components intelliently without much human-intervention, accompanied by a run-time alorithm that uses modication of an existin backend (Doorastha [Dah00]) for distribution. 1.3 Problem Statement This thesis proposes a novel architecture for application partitionin - an automated, object-level, dynamic, run-time partitionin system, more specically a distribution analyzer and decision enine. We believe, that proposed architecture, would be an ecient and exible solution to the application partitionin problem. We have identied dierent issues involved in each component of the architecture and suested solutions for the same. The key ideas which make our approach novel, include the followin: Finer ranularity of components, considerin objects and not the classes. A statistics-based dependency model to represent interdependencies between application components. A truly dynamic, run-time allocation scheme for distribution of components We feel that ner ranularity partitionin decisions, would lead to more exibile and ecient partitionin mechanism. In addition to the ranularity of partitionin, it is also important to decide the placement of dierent components on available hosts. Finally, we stronly feel that there are numerous factors that can aect object allocation decisions, some of which come into picture at run-time. The existin systems are limited in the sense,

16 Thesis Outline that they statically decide the component allocation, before the execution of proram. Most of them depend on user-specication and do not emphasize on intial placement decision. This certainly is not a very ood idea for lon-runnin, lare-scale prorams, havin multiple components. We have implemented a statistics-based Decision Analyzer. This tries to learn and represent dependencies as well as independencies (between the components) as a probabilistic model. The run-time alorithm uses and updates this model. It is exible enouh to account for factors like load distribution, and hence is truly dynamic. We have used Java for the demonstration of our ideas. However, the ideas discussed are in eneral applicable for OO lanuaes. 1.4 Thesis Outline Chapter 2 discusses related work in application partitionin, based on which we propose a taxonomy for application partitionin. Chapter 3 discusses the various blocks of proposed O-L partitionin architecture includin the vrious desin decisions that were taken. Chapter 4 hihlihts the implementation details. Finally, we conclude in chapter 5 hihlihtin some limitations and future work.

17 Chapter 2 Related Work 2.1 Introduction The idea of distributed computin was introduced, based on RPC by lanuaes like Java. RMI 1, CORBA in Java or DCOM in C++, allowed user to access remote objects, and execute methods on them. However, all these are more suited for desinin client-server paradim based architectures. After these, there came up systems, which were built over middlewares like RMI/CORBA. They enable easy code eneration, for remote objects. These were then built upon by front-end systems which used some partitionin strateies to identify components to be distributed. The problem of partitionin in literature has also be dealt with mechanisms that work by modifyin the execution environment of application. This has been referred to as the implicit approach in [Spi02]. These systems do not rely on the prorammin lanuae. Instead, they use a Distributed Shared Memory(DSM) environment. DSM mechanisms involve cachin and replication, which can be done at dierent levels like pae and object. Thouh they make thins more transparent, as discussed in [Spi02], the eciency of these systems is not very commendable. Also, they are often non-standard and cannot be extended to dierent machine architectures. Thus, we have restricted our focus to what has been referred to as explicit approach in [Spi02]. To explain briey, explicit approach works from within the prorammin lanuae, rather than modifyin execution environment. Thus all the solutions that we discuss, actually form a layer above the standard middleware of the correspondin prorammin lanuae, and hence are more standard. The related work has been discussed under four heads. Section 2.2 discusses in brief about existin standard middlewares. Section 2.3 discusses the work done on the distribution infrastructures. Distribution infrastructures implement distribution policy, suested by the partitionin stratey. Section 2.4 discusses the existin work on partitionin strateies and mechanisms. 1 Remote Method Invocation 5

18 Existin Middleware Technoloies 2.2 Existin Middleware Technoloies Popular prorammin lanuaes like C++, Java,.NET provide distributed constructs for remote execution. This desin is reatly inuenced by the RPC mechanism. In the RPC mechanism, the caller invokes a dummy procedure(stub) on local machine, and this inturn sends network messae to the server which ets the method executed on actual object and returns the results. RMI does this at object-level. Each remote object has a stub which acts as a proxy at the client site for transferrin the call to the actual object. RMI [RMI96] is Sun's proprietary client-server oriented distribution technoloy for the Java lanuae. It allows the prorammer to create remote classes, i.e. classes that implement the java.rmi.remote interface. The user also provides an interface listin all the methods that may be called remotely which enforces such methods to be public. It uses the concept of reistry or name server, which hosts the objects. Each object is bound with a specic name on the server. When queried, the object server then returns a remote reference of object. This reference can then be used to invoke remote methods. Once the objects are reistered by the RMI system, they are represented as network references and remote objects are always passed by-refvalue. The backend used in current implementation is based on RMI. CORBA is based on the same basic principle, except that its more useful for interoperability between dierent platforms. DCOM for C++, aain uses the same concept of interfaces and stubs. The essence is that usin existin middleware standards, codin a distributed application requires a lot of plannin in the desin phase of application itself, concernin where dierent objects and classes should be created and how they should be accessed. Moreover, it is a lot of hassle to actually code such an application, because of special remote-enabled code constructs.

19 2.3. Distribution Infrastructures Distribution Infrastructures We dene Distribution Infrastructures as systems that form a thin layer over the middleware. These when provided with detailed distribution policy specication, usually work by code transformation and some extra code eneration. These systems have to deal with issues a little more specic to the middleware bein used. Most of the systems based on Java use RMI Issues Related with RMI RMI constructs in Java try to minimize the dierence between distributed and nondistributed syntax. Thus method invocation syntax is similar to that of eneral nondistributed Java prorams. However, there are certain issues that arise when we try to use it for distributin a eneral-purpose OO proram. First of all, each remote class should necessarily have an interface and an implementation. In addition, the exception handlin is not very convenient. Actually RMI was basically desined for client-server applications and so is not very convenient to proram a eneral OO system with inter-class relationships. Below is a list of few issues that arise when RMI is used for prorammin a eneral OO proram. Static and nal methods cannot be dened in RMI implementation classes. RMI only permits the use of public and abstract modiers for the method declaration in remote interfaces. Also in cases where class is hosted on multiple nodes, handlin static elds is a problem if they are not constants. Consistency of Object References (Identity of Objects) { Equality operator for remote objects(equals or == ) may not work properly. For e.. If two remote references of same object obtained from dierent sites, the == operator only compares references, and does not work accordin to OO semantics. { Reference translation does not happen when object is moved amonst multiple hosts. To explain further, if an object is passed from site 1 to 2 and then 3; when referenced from site 3, the object would be referred via site 2. Local object reference retrieved from a remote host as a RMI reference has to be accessed via indirect path. System Classes (with and without native code). Source code for system classes is not available. Thus we cannot expect system objects to be remotely accessible. But objects of system classes like Vector, if be dened remotely can help improvin performance.

20 Distribution Infrastructures Inheritance Super class needs to extend UniCastRemoteObject, even if sub-class needs to be made remote-capable. This does not seem to be quite correct if we o by OO semantics. { All implementation classes need to extend from UniCastRemote Interface. In Java, only sinle inheritance is allowed. This implies all super classes need to be modied (OO paradim violation). Transformations may cause breaks in inheritance chain and instance of, sub-classin may not work as in a centralized proram. { In case of classes extendin system classes, this too is not possible. Methods with packae scope have to be made public as the interface methods have to be public, or otherwise all packae references should be uaranteed local. Aruments By default a non-rmi object is passed by-value. System Objects cannot be made remotely accessible. If all the objects are made remote capable, we can handle usual pass-by-reference semantics of Java prorams. However, this may be too expensive in some cases. Based on these considerations for remote execution in addition to usual passin modes(by-value, by-reference) followin modes can be dened. { By reference value(ref value) The callee operates on the oriinal object via the iven reference and thus may alter its state. However, the reference cannot be modied. This mode is used when a centralized Java proram runs. { By copy The callee operates on a (deep) copy of the oriinal object which itself remains unaected. { By visit The object is moved back, after the invocation returns. { By move Here, the runtime system moves the object physically into the callee address space, and redirects any old references. Handlin of synchronized classes RMI does not allow synchronized methods to be declared in interface dened for the public class. Slow marshallin and de-marshallin process - RMI stubs serialize all the parameters bein passed(except network references) on a remote invocation. This process is very time consumin.

21 2.3. Distribution Infrastructures Distribution Infrastructures as backends These distribution infrastructures have been used as backends. The partitionin schemes as discussed in section 2.4, enerate a distribution or a partitionin policy, which is implemented at run-time by these backends with remote enabled code over the middleware. These systems allow specication of distribution policy for each class and its methods. The specication details some of the followin: 1. Location of the class if needed to be xed on one node J-Orchestra[TS02] 2. Location of an object when bein instantiated Doorastha[Dah00] 3. Parameter passin mode(visit, move, copy) for formal aruments for each method. 4. Classes can be taed as miratable in which case at run-time their instances can mirate to other nodes as aruments or return values durin a remote method invocation. Most of the systems have used statically determined positions computed by analysis or specied by the user. Thus run-time system never has to bother about the position of object. Some of the ways used to specify the distribution policy include the followin: 1. Additional Constructs: Additional keywords and constructs extendin Java lanuae are provided to declare remotely accessible classes. Java Party[PZ97] 2. Comments: Comments written above the classes in a specied format. Doorastha[Dah00] 3. Conuration File: Have conuration le per class. J-Orchestra[TS02], uses an XML con le, Addistant [TSCI01] uses a special conuration le, indexed by hosts for the same. These systems have a translation component which processes the distribution policy and transforms the source code into remote-enabled code accordinly. Another major task is to handle the various issues related to the middleware (RMI). There are a number of systems that provide such infrastructure support. Javaparty[PZ97], Doorastha[Dah00], J-Orchestra backend[ts02], Coin Backend[HS99], Addistant[TSCI01].. Most backends try to solve the issues hihlihted above. We are discussin the architecture of Doorastha in detail, as it has been modied and used as distribution backend in our architecture Doorastha Doorastha [Dah00], has a compiler subsystem that uses annotations within the source code (as comments), to enerate the RMI equivalent code.

22 Distribution Infrastructures Translator The Doorastha translator, apart from code conversions necessary to handle the RMI issues as discussed in section is responsible for maintainin transparency between remote and local object communication The key principle, which has also been used in javaparty[pz97], J-Orchestra backend [TS02] is a proxy-based approach shown in Fiure 2.1. This approach tries to maintain the transparency between local and remote Fiure 2.1: Proxy-Based Approach-Transparent handlin of remote and local references references of an object bein accessed by makin use of elicit mechanism of inheritance and polymorphism. More details can be referred from [Dah00]. The translator enerates the necessary code to implement the same Runtime System Doorastha run-time is a distributed alorithm, where run-time entities sit at each host and interact. This sub-system manaes translation of object references at run-time. It provides object factories at each host. Also, it maintains references of all objects, instantiated on a particular node. It manaes network-related issues like resolvin host-names etc. It manaes the start-up and runnin of run-time systems at all the hosts. It also helps manain dierent arument-passin modes by providin support for miration.

23 2.4. Partitionin Schemes Partitionin Schemes The distributed infrastructures discussed in section 2.3 expect a detailed specication about component. Specication in literature [TS02] has been dened as - the location of component instantiation, its mobility, and if it is dened miratable, a miration policy describin when it will move. This can be dened by specifyin the parameter-passin mode(visit/move, reference, value) in the conuration le for each function. We have mainly concentrated on initial placement as of now. Thus the distribution policy too considers the same. A partitionin scheme tries to use some heuristics to enerate a distribution policy. Hiher distribution causes more components to be distributed across dierent hosts. With increase in distribution, more local interactions are converted into remote. Remote invocations increase network overhead. Thus thouh various reasons suested above in section 1.2 motivate to distribute, the tradeo is that distribution increases remote communication overhead. A partitionin mechanism should try to balance between these two contradictin factors. We have identied some factors, that can be used to characterize a partitionin scheme Features of a Partitionin Scheme Granularity of Distribution Component Usually an OO proram comprises of classes and objects, and hence on the basis of ranularity of partitionin component we can classify the existin partitionin schemes. 1. Class-Level Partitionin This kind of partitionin aims at roupin closely interactin classes toether. The source code comprisin of dierent classes can be divided across the hosts. Some systems may also support replication of classes. This kind of partitionin is based on the assumption, that objects of a sinle class exhibit similar behavior, and will be usin same resources and hence should be instantiated on the same host. In a nutshell, all objects of one class are created on same host. Moreover, classes are clustered into roups. 2. Object-Level Partitionin This kind of partitionin aims at clusterin of objects. Object level partitionin stems from the aruments like - reusability bein an important aspect of OO prorammin, objects from the same class may exhibit dierent behaviors when they interact with dierent objects. Also, allocatin all objects of one class to one node is a reat limitation. Thus O-L Partitionin, does not primarily aim at division of source code, but division of objects across the hosts.

24 Partitionin Schemes Analysis Techniques The partitionin scheme needs to identify closely interactin components so that they can be co-located. This involves proram analysis, to identify dependency relationships between the components. The analysis can be static which can in turn be at source level or bytecode level. Alternatively, prolin can be used, to study the component interactions and subsequent los be then analyzed and classied. 1. Static Analysis Involves techniques like, call-raph creation and doin dependency analysis based on it. Available libraries for code analysis can be used. Source-code level analysis are more easy to understand, whereas Bytecode level analysis techniques are extendible to system classes. 2. Dynamic Analysis Involves instrumentation of the existin code, to prole application runs. This prolin aain can be of two types. It miht be on the standalone code itself, or remote-enabled code Allocation Decision This feature is based on the time of actual allocation decision. All the systems we know of, work by pre-decidin the component allocation before the execution of proram starts. 1. Oine Component allocation is decided and specied in some conuration le or in the form of annotations within the proram. 2. Online Component allocation decision is postponed till run-time. As per our knowlede, there are not any such systems usin online techniques as yet Addistant and J-Orchestra J-Orchestra [TS02] is a class-based partitionin mechanism. J-Orchestra also has a backend as discussed in section 2.3. Addistant[TSCI01] has a conuration le, which can be indexed by hosts. This le is used by the backend for code eneration. For each host, a class-level or packae level specication may be done. J-Orchestra too has a similar conuration le, where-in for each class, properties can be specied. For J-Orchestra however, partitionin mechanism, is expected to enerate this le. Once the host specication has been provided, J-Orchestra allows user to dra and drop classes to dierent hosts. The classes however et allocated in roups. A static analyzer and proler component are used to each time verify the oodness of partitionin

25 2.4. Partitionin Schemes 13 by prolin. It reports statistics on the interdependencies, based on which an ecient conuration can be decided. Major contribution of addistant and j-orchestra has been to enable distribution of leacy software. Operatin at bytecode level, they try to make objects mobile at runtime in the presence of unmodiable code (like that of JNI) Panaea Panaea [Spi02] uses Doorastha [Dah00] as the backend. Panaea does a primitive level of Object-level Partitionin. It uses a raphical tool to represent the proram structure as an object-raph. This object-raph is built usin purely static analysis of the code. An object raph Fiure 2.2, represents the followin: - The type information (data type) is considered and the data ow at the type-level is represented as a raph. - Dierent types of objects - static and dynamic (Concrete and indenite) are identied, for each class. The concrete are the ones which are certain to take specic value on creation. The indenite ones may assume one amonst a rane of values. E. Producer in producer/consumer example is concrete whereas an inteer could be indefinite. Dierent constructs of the proram - Constructors, static initializers, main(), Thread.run() Fiure 2.2: Panaea - Object Graph etc have been used to cateorize all the objects into the above cateories. Such objects become the nodes of the raph - Edes encode the followin relationships between the objects - Creation, Usae, reference(import, export). These can be identied by the analysis of method aruments, return types etc. - The object denitions are applied recursively and added to the raph. E. For each concrete object, concrete and indenite objects are added for the elds etc accordinly. - Finally, the references are propaated transitively. Once the object raph 2.2 is constructed its displayed to user, and user can assin objects to dierent hosts. For numerous objects round-robbin allocation is done amonst the hosts. Panaea then enerates the actual annotated code that can be interpreted by Doorastha Coin Coin [HS99] is implemented for COM-DCOM systems. It can support object-level partitionin. Input to the Coin system, is a COM application. Coin instruments

26 Partitionin Schemes and proles this application by invokin DCOM code, to actually calculate the cost, if components were distributed. A component can be a class or an object. Coin supports dierent types of classiers. The system can thus be conured to dene an appropriate component. Two of them for e are - Static type Classier : Classication descriptor is just the type. I3C Classier : Classication descriptor is full component call chain of instantiation request, concatenated with static type. Coin then creates a component raph, where nodes include the dierent component descriptors and edes represent the communication costs, calculated durin prolin. As Coin considers communication between remotely located components by-copy, all the functional aruments add up to communication costs. This raph can then be partitioned usin a standard raph partitionin alorithm, into number of partitions equal to number of hosts. The system has been mainly tested, for client-server applications.

27 2.5. Application Partitionin - A Taxonomy Application Partitionin - A Taxonomy Based on our study and analysis, we present a taxonomy of possible application partitionin approaches in Fiure 2.3. Application partitionin can be dealt with implicit or explicit mechanisms. Explicit mechanism based solution should have a partitionin stratey and a distribution backend. Distribution backend implements a partitionin policy specied by the partitionin stratey. Partitionin stratey aain can be classied on the basis of ranularity of partitionin component, allocation decision and analysis technique. Fiure 2.3: Application Partitionin Taxonomy The related work has been partly concentrated on distribution infrastructures - Doorastha [Dah00], Javaparty [PZ97], Addistant [TSCI01]. Thouh J-Orchestra does some static analysis, its major contribution has been on the distributed infrastructures front. Panaea [Spi02] advocated O-L partitionin in a very limited sense. It needs user to specify allocation details. Coin[Hun98] is O-L system, but has other drawbacks as discussed in section Its primarily desined for COM but still tries to eliminate human intervention. COM does dynamic analysis(prolin), but its done on DCOM based code.

28 Application Partitionin - A Taxonomy As per our knowlede, there does not exist any system which takes run-time allocation decisions. Also, none of the systems have a sophisticated analysis technique. Panaea and J-Orchestra do static analysis and are hihly user dependent. Coin does dynamic analysis and prolin but has the limitation that passes all aruments by complete copyin. In the next chapter3, we discuss our architecture for an object-level, dynamic analysis, and run-time allocation-decision based automatic partitionin system.

29 Chapter 3 Object-level Partitionin - Architecture and Desin 3.1 Introduction and Motivation This section discusses the detailed desin of an object-level, dynamic, automatic partitionin system which takes run-time allocation decisions. The key motivation behind this architecture is, that we want to exploit as much information as possible (available), oine and yet provide enouh exibility at run-time, to relocate object allocations dependin upon load distributions. Dynamics of an application are decided at the run-time, where objects are most relevant to partition. O-L partitionin as discussed in Section aims at clusterin closely interactin objects, to optimize on network overhead, while the application is distributed across a network of hosts. We stronly believe that O-L partitionin is an ecient partitionin technique motivated by the followin reasons: Importance of has-a relationships Class represents the behavior of a proram component, whereas an object is its instance, actually functional at run-time. Classlevel partitionin systems view proram as a collaboration of classes and inore the has-a relationships. A class can have multiple instances. Multiplicity of objects is one aspect which cannot be considered while doin a class-level partitionin. Instance Behavior In literature, most of the work has been on partitionin the application by placin its classes on dierent nodes. However, an important point here to note is that in a lare application, one class may be interactin with many other classes, which in turn may not be related at all. To explain with an example, we can consider distribution of a proram comprisin of Vector class 3.1 bein used by two totally unrelated classes for storin objects. Now keepin Vector class and all related classes on one node or makin remote references for all classes is not a ood idea. The key point to note here is that instances of vector class may be useful in two totally dierent contexts and hence we arue that a distribution policy considerin distribution of objects is more plausible. Arument Passin Modes Another point to be considered is that in class-level partitionin systems, while denin properties of the class-methods, we x the 17

30 Introduction and Motivation Fiure 3.1: Class vs Object Level Partitionin parameter-passin mode (call-by-visit/call-by-move/copy) for each method. Multiple invocations of the same method however by dierent classes, may make more sense to have dierent callin modes at runtime. Specially, if the class can be used in dierent contexts and its dierent instances are distributed. O-L partitionin surely provides reater exibility as far as the partitionin and distribution is concerned, but is complex to implement. In a lare-scale proram, however, where there are heavy objects, it certainly makes sense to consider dierent application scenarios, and object level interactions and then place the object. Section 3.2 describes an overview of architecture partitionin system. Subsequent sections then elaborate on dierent blocks of the same.

31 3.2. Architecture for Object Level Partitionin Architecture for Object Level Partitionin As discussed above in section 2.4, none of the existin schemes provide much exibility. We have tried to make this as exible so that it can be further extended to incorporate as many as factors possible at run-time. Fiure 3.2: System Overview The system as shown in ure 3.2 beins with the input of application source code, written for standalone environment. This code is analyzed by the dependency analyzer to enerate a model representin dependency relationships between the objects. The dependency analyzer also plays the role of identifyin dierent contexts in which objects may be created. This code is then iven to a translator, that uses some code analysis/manipulation library to enerate a remote enabled code. At run-time then, as proressively objects are allocated, all the available information is used to predict the most suitable location for object allocation. The run-time sits as a layer above RMI. In the next few sections, we discuss each of the blocks of the proposed architectures in detail accompanied with a tested example to illustrate our architecture.

32 An example 3.3 An example This is a very simple proram as depicted by the class-diaram in ure 3.3. The source code for the example is attached in the appendix A. We assume that there are three hosts available for placement. We will walk throuh this section illustratin this example to explain the functionin of each block. Fiure 3.3: An Example

33 3.4. Dependency Analyzer Dependency Analyzer The oal of a dependency analyzer is to learn application patterns, dependency relationships between the dierent components and represent it in a model that can be used at run-time. Fiure 3.4 shows the architecture of our dependency analyzer. The standalone code is instrumented and proled to enerate dependency related information. There can be several such runs of the proram. These can then be used by a learner to learn object dependencies. Fiure 3.4: Dependency Analyzer Section explains the need of a distribution analyzer. Subsequent sections mainly elaborate on the learner, illustratin our analytical model and justifyin its applicability Sinicance of initial placement We feel stronly that there is a need for an optimal partitionin stratey, if partitionin process has to be completely automated. Even if backend provides miration support, miration of heavy objects can often be a network overhead. Thus, a ood partitionin

34 Dependency Analyzer software must try to optimize initial placement of object. Now there are several factors that may inuence placement of an object O. Location of other objects that invoke methods on O Resources accessed by O. This is more class-dependent Control ow of the proram, which miht inuence creation of other objects, that may be accessed by O and thus indirectly the placement of O itself. Host-load scenario Statistical Approach to O-L Partitionin O-L partitionin aims at optimal placement of components - instances, to the most optimal position in the network at run-time, so as to minimize the communication overhead as well as use the distributed environment. Component interactions can be minimized, if hihly interactin components are co-located as discussed in Section We propose a slihtly dierent approach to this problem, based on machine learnin. We suest the use the prior knowlede available from prolin and represent it as a model. A probabilistic model is apt because if we have numerous runs of an application and a lare prolin data, a dependency model ttin most of the runs of the application can be built. Thus we suest the applicability of dependency-based classication techniques for this problem. The idea is to train a classier from the prolin runs for an application. This classier can be used to classify the instances at run time to dierent hosts. We however think, that this should be a case of active learnin classication as dependin upon the environment, the model should keep on adaptin Bayesian Belief Networks - Applicability Before explainin the details of the model, we would like to specify clearly what a component denotes in our desin. Each component in our system is identied by its unique call-trace(the exact sequence of method calls which led to the creation of the instance). It has a class-type(the class of which it is an instance). Thus one class can have multiple components represented. We are tryin to model the relationships between these components, on the basis of references. Bayesian Belief Networks [BBN98] is a well-known statistical modellin technique. BBNs model relationships between the dierent variables by representin the conditional dependence as well as independence between them. Structurally, BBN is a set of nodes and arcs. Nodes represent the variables. Each variable can assume a set of values(discrete/continuous). These values are also termed as class attribute 1 sometimes. 1 BBN is a well-known classication technique

35 3.4. Dependency Analyzer 23 Fiure 3.5: BBN - An Example network Arcs between the nodes represent dependency relationships. Each node is annotated with a probability table. Each row of this table, denotes a probability - the chance of variable to assume a value conditioned on dierent values assumed by its parents 2. Each combination of values of variable and its parents is a separate row. An example BBN could be as shown in Fiure 3.5. The BBN can easily be used to represent the followin: Conditional dependence as well as independence of objects on other objects. Cumulative eect of already allocated objects on other objects. Communication Overhead can be incorporated into the probability tables of nodes. We assume that objects are always passed-by-reference between components(as aainst Coin2.4.4). However, the interaction between the aruments passed when componenta invokes a method on componentb, passin componentc as arument, can be accounted as interaction between C and B. Thus DAG very aptly capture the dependency relationships between the objects. BBNs can be extended to also handle, dierent application control ows, and incorporate them usin probabilistic BBN learnin alorithms. Dependency information athered from dierent prolin runs, can be combined by a learner to develop a model. BBN learners can use this data as trainin data. Each prolin runs' output suests a dierent BBN structure. The BBN learnin would therefore be a kind of search amonst these structures, for an appropriate model. 2 Parents of node A, include nodes havin an outoin ede to A

36 Dependency Analyzer Dependency Model We model each component(as dened in 3.4.3) in our system as a Bayesian Node. The set of hosts represent the class attribute for each node. Thus each arc represents dependency between the components. Each row of the probability table denotes one conuration 3 of parent objects and the correspondin node. Accordin to the approach proposed, if we have lare los indicatin instantiation histories over several runs of the proram, a BBN learnin alorithm [Bou94] could be applied to learn a model that would be true representative of the application behavior for most runs. This would include the followin : Number of times that component occurs in all runs, and for each such existence, number of times a reference from a particular incomin parent was made. Averae communication overhead. This overhead would involve : { Number of times the two components communicate { Cost of exchane of immutable parameters like Strin 4 and others that are passed by total copy(if any) Location Constraints can be modelled in probability tables. By location constraint we mean that instances of a few classes may be constrained to be anchored on particular hosts Simplistic Version of the Model For the purpose of demo and to maintain simplicity, we have considered a sinle ow of application. For this sinle ow we try to develop a model, without usin specialized learnin alorithm. As per our simplistic version of the sophisticated dependency model, arcs of BBNs represent the referred to and referred by components for each node(component). We also consider communication overhead between two components as just the number of remote invocations Mathematical Formulation of the CPT Let the number of interactions of a component C i with component C j be N i;j. where C j 2 parent of(c i ) Number of rows in the CPT, sizeof(cp T ) = num of hosts num parents+1 (3.1) 3 object to host mappin 4 Java.lan.Strin

37 3.5. Translator 25 For a particular conuration(allocation) - A i;k, involvin C i and its parents 5, representin the k th row of the CPT, where H(C i ) represents the host allocated to component C i Number of remote invocations, R Ai;k = P H(C i )6=H(C j ) and C j 2 parent of (C i ) Chance of a conuration k denoted by chance Ai;k chance Ai;k = sizeof(cp T ) P is then computed as R Ai;t The CPT value P i;k for the k th row can then be computed as N i;j (3.2) t=1 (3.3) 1 + R Ai;k P i;k = P sizeof(cp T ) t=1 chance Ai;k chance Ai;t (3.4) For our example illustration, dependency analyzer takes as input the oriinal source code of appendix A and enerates a model as shown in appendix B.4. Further detail will be explained with implementation details in the chapter Translator The translator transforms the proram to incorporate remote capabilities. This component is dependent to a reat extent, on the middleware bein used.. Followin are the main features of a translator. Translator makes code remote-enabled. It takes code taretted for a standalone system, and transforms the classes, eneratin the interfaces and middleware related code. Followin code instrumentations are needed: { Object creation - Each new() has to be transformed to a query to run-time analyzer and followed by call to remote/local run-time system. { Method invocation - A function call will have to handle parameter passin modes or may have to make a previously local object remotely enabled etc. Similarly a return may need to create a remote reference to an existin local object { Method Return 5 This represents one row of the CPT

38 Translator Limitations of the middleware e.. those for RMI, hihlihted in section have to be handled. Code transformations may need to be made for the same. Code replacements E. Replace direct eld accesses by etters and setters, packae-scope access modiers, handlin ==,.equals operator etc. In addition it also involves handlin of some specic constructs E. static, synchronization, threads, inner classes, reection etc. Translation can be aain done at source code level 2.4.3as well as bytecode level as in The latter has the advantae that it can handle system classes as application classes except those usin machine-dependent constructs. However, the techniques discussed above should be applicable to both. We do not consider machine-dependent classes. J-orchestra2.4.2 exploits all the details for the various combinations of modifyable and unmodiable code and also discuss the solutions for the same. Code transformations from J-Orshestra can be added to a translator to increase the exibility of object allocation amonst the hosts. For the purpose of demo, we have only included application class objects for distribution.

39 3.6. Run-time Analyzer and Query Enine Run-time Analyzer and Query Enine Object allocation decision Fiure 3.6: Runtime-Analyzer Runtime decision on object allocation has been motivated for us by followin reasons: Postponin the nal allocation decision increases the exibility in allocation. It can help adjustin to varyin load scenarios on the host nodes. It can also help adaptin to situations like those of varyin resource locations(e.. Database Miration). Dierent control ows can lead to dierent sets of instantiations and hence, a more accurate placement, inuenced by already allocated objects will be taken. At run-time, we would like to use all decisions made reardin the components already instantiated, to be used as evidences. The load balancer feedbacks can be incorporated as weihts of hosts. This updation can be an external feedback from load-balancer, which obviously would present the actual load condition of the system.

40 Run-time Analyzer and Query Enine Functionin of Run-time Analyzer We have used, JavaBayes [jav98]. The functionin of the run-time analyzer has been explained in Fiure 3.6. This component plays the most important role in makin the architecture exible. The run-time analyzer as in our architecture is like a central oracle, for the system. It maintains the model learnt durin the oine phase. Runtime analyzer, is queried by the run-time system 3.2of each host whenever an object has to be created. Run-time analyzer uses the dependency model learnt by analyzer, propaates the current allocation as evidence in the BBN and updates the structure. We can use a standard BBN Inferencin software. We have used JavaBayes [jav98]

41 3.7. Run-time System Run-time System We briey explain the workin of our runtime architecture with our illustration. As specied in section 3.3 there are three hosts available. Fiure 3.7 illustrates the workin of runtime. Runtime is a distributed component sittin on each of the hosts. For the purpose of illustration, we x analyzer - the central oracle at Host-1. Suppose the main() of the proram starts at Host-3. When Host-3 ets a request for new object, it invokes the analyzer on Host-1 in step-1, sendin the current stack trace of the thread. Host-1 uses the runtime-analyzer and returns with some host say Host-2 in step-2. Followin this, Host-3 invokes the runtime object factory at Host2 in step-3 that instantiates a new object of specied type and return a remote reference in step4. Run-time system oers the necessary support durin execution to et the proram executed in distributed fashion. Fiure 3.7: Illustration of the runtime It is a distributed component present on each node where objects can be hosted. It interacts with the run-time analyzer, passin it necessary parameters like creator class, method, stacktrace of the thread, etc. Once the location of an object be decided, run-time provides object factories- one per node, binded as a well-known object. These factories handle creation requests for local as well as remote sites. It handles translation of references as the objects are passed as aruments to methods.

42 Comparison with the Related Work Ideal run-time system will support object miration as well and support modes like - call by visit/move and copy It maintains the information needed like stacktrace of the thread over the distributed nodes in a distributed fashion. Run-time systems at all nodes act as peers, manain object creation and references. 3.8 Comparison with the Related Work We expect that the above architecture would be more ecient and prove more exible than the existin softwares. In this section we try to compare our proposed approach to existin mechanisms. In literature [TS02], [Dah00],[PZ97], much importance has been iven to the backend systems, that manae object references at runtime and provide support for miration. Firstly, the analytical model that we propose usin statistical approach is a novel idea. Most of the systems in literature as discussed in Section 2.4 do static analysis. Dynamic analysis has been done in Coin with DCOM enabled code. We emphasize the sinicance of initial placement of the component. Most systems namely, [Spi02], [TS02] believe in user specifyin the initial position of the component(object/class). Thouh this provides room for user customization, a truly automated partitionin system can actually do some intellient work on this placement. We have identied some factors as discussed above and we incorporate them in our model. Secondly, none of the existin systems we know, support run-time decision based allocation. The usual desin of existin systems has been, to do some analysis (mostly class-based dependency), and enerate an allocation/partitionin policy oine. Panaea- Doorastha, section and for example, would let specication of each object as annotation within the code. However, this means that whenever a particular new instantiation has to be done it will be on a xed host. J-Orchestra, section on the other hand, tries best to make each object mobile(system class objects), so that it can be passed around as when instantiated from one host to other when functions are invoked. We arue that relyin on miration is not a very ood idea. Most work has been on the backend front, where policy is hihly dependent on user specication. The system closest to our desin is Coin [Hun98]. However, Coin mainly desined for COM-based systems is mostly taretted for client-server architectures has other shortcomins as hihlihted in Section Our idea of object classication is inuenced by Coin's I3C classier.

43 Chapter 4 Implementation Details We have shown the feasibility of this architecture, by implementin dierent blocks. This section hihlihts a few details of the implementation. We have implemented the entire architecture of the decision analyzer, as discussed in Section 3.2. The translation alorithm is straihtforward. We assume thus handcoded instrumented code to be the input of our implemented run-time alorithm. The desin of translator is discussed in Future extensions at the end of this chapter. The runtime analyzer uses a standard bayesian inferencin software. The run-time infrastructure, is a modication of Doorastha [Dah00]. It provides some features that our architecture proposes as a part of the run-time system. This has been discussed earlier with distributed infrastructures as explained in section 2.3. We have modied Doorastha run-time to provide basic run-time support. 4.1 Standalone Prolin As discussed in Section 3.4, we use dynamic analysis or prolin for dependency analysis, but do it oine, with standalone code. We have used Java Virtual Machine Tool Interface [jvm04] with JNI support. Prolin works by code instrumentation and event trappin. In other words, jvmti provides us an API throuh which we can dene our aents and execute necessary code on notication of dierent events like - JVM start/end. The code has partly been written in Java and partly in C. The Appendix B details further. Appendix B.1 is the Tracker class. The standalone code for prolin is instrumented to invoke methods of this class. The actual prolin which involves object tracin, method tracin, object-stacktrace maintenance and dependency matrix eneration is done in native code. The other options considered for prolin were - JVMPI [jvm], java.lan.instrument API [jdk96]. The former is now out-of-date and latter did not provide object tain which C interface allows. There exist some prolin tools yajp [yaj], [ejp], but most of them provide class based information and not object based. Fiure 4.1, shows the main loic used in the proler. We have used bytecode instrumentation, to record method invocation and object creation events. The output of prolin is : 31

44 Codin the object model - BBN Fiure 4.1: Prolin Flow 1. Object Information table - Unique stack traces encountered and their ids. Appendix B.3 shows the output of a sample run on the Motor car example. Each row of this table sinies one unique object type annotated by a unique stacktrace. Each class is represented as one object type too. This has been done for static data representation. All static methods invoked use this class-id. 2. Dependency Matrix - M(caller,callee) is number of times object id caller invoked a method on callee. Appendix B.3.2 shows a part of the matrix learnt. 4.2 Codin the object model - BBN For simple demo of the system, we have demonstrated Model learnin for a particular ow of the application. We have implemented a simplistic model as discussed in section The dependency data is just based on standalone prolin runs, and hence is independent of host knowlede. However, as discussed in section , the run-time will query the model for best location. Thus, the learner has to have a small component which we call BBNenerator. The BBNenerator, computes dierent combinations on object allocation based on each

45 4.3. Run-time Issues 33 Fiure 4.2: BBN Generator parent and calculates the CPTs for each node. In our system with simplistic model, it implements the alorithm discussed in section This codin is done in C. The Bayesian network learnt is represented in standard BIF(Bayesian Interchane Format) [bif98]. 4.3 Run-time Issues We have modied the Doorastha [Dah00] to incorporate object-level partitionin run-time alorithm. We needed to add support for interfacin with the analyzer enine. We have added support for maintainin the thread stacktrace durin the distributed execution, which is needed by the analyzer to index object creation requests in the object repository. 4.4 Extensions to the current Implementation Here we hihliht the desins of the components which could not be implemented, due to constrained time.