AL-1/D: A Distributed Programming System. with Multi-Model Reection Framework. Yutaka Ishikawayy.

Transcription

1 AL-1/D: A Distributed Programming System with Multi- Reection Framework Hideaki Okamuray okamura@mt.cs.keio.ac.jp Yutaka Ishikawayy yisikawa@etl.go.jp Mario Tokoroy 3 mario@mt.cs.keio.ac.jp y Department of Computer Science Keio University Hiyoshi, Kohoku-ku Kanagawa, 223 JAPAN yy Electrotechnical Laboratory Umezono, Tsukuba Ibaraki, 305 JAPAN Introduction We have proposed the Multi- Reection Framework [3] where an object is described by multiple models each of which abstracts the object behavior in the dierent level, i.e., from the operating system level to a high-level programming language level. In one model, some objects called meta-level objects are constituted to describe the behavior of an object called a base-level object. An object is causally connected with its multiple meta-level objects, so that the object may have the ability to modify its behavior by the modication of those meta-level objects. In this paper, the application of Multi- Reection Framework to a distributed system is reported. In a traditional distributed system, the operating system (or the runtime library) supports for the network transparency. By the network transparency, we mean that the user do not need to take the nature of the distributed environment into account. In the distributed system, the system needs to automatically change the conguration to balance the CPU's and communication load and make the system reliable. If the functionality of the dynamic conguration is effectively operated, users are satised with the system. However, most cases fail because it is dicult for the operating system to recognize the application's behavior without any hints. Rather, some users know the application's behavior. They are willing to change the conguration of the distributed environment in order to run their applications eciently. The requirement of the network trans- 3 He is also with Sony Computer Science Laboratory Inc., Takanawa Muse Building, Higashi Gotanda, Shinagawa-ku, Tokyo, 141 JAPAN, mario@csl.sony.co.jp parency and the change of the distributed environment by the users is the contradiction. By Multi- Reection Framework we are able to create several dierent models in the distributed environment. Some models abstract the object behavior in the network transparency. That is, the object behavior is described in the location independent. Using other models, the object behavior in the distributed environment is considered. The AL-1/D, a concurrent object-based programming language, has been designed and developed based on the framework. Firstable, Multi- Reection Framework and the object model of the distributed environment are introduced in this paper. In section 3, the syntax and the semantics of AL-1/D are shown with examples. The design and implementation of AL-1/D are presented in section 4. In section 5, we evaluate the performance of AL-1/D system. Finally, we conclude this paper with mentioning future works. 2 Multi Reection Framework 2.1 Concepts The concept of Multi Reection Framework is summarized. As show in Figure 1, an object is modeled by the multiple dierent levels in the Multi Reection Framework. The principle of this framework is as follows: An object has its state which is changed at an event, 1

2 Meta1 Object Meta2 Transparent to Distributed Environment System Language Statistics Meta4 Meta3 Level of Abstraction OS Operation Resource DE Migration Base-level Object Not Transparent Figure 1: Multi- Reection Framework i.e., message arriving, message sending, and so on [3]. The object behavior is dened by its state and the action at the state change. An object is represented by multiple models each of which describes the object behavior in the dierent abstraction. The object is called a base-level object. In a model, the behavior of a base-level object is described by a meta object which consists of several objects. The meta object denes actions at the state change. A base-level object and its meta objects are causally connected so that the modication of those meta objects is reected in the base-level object behavior, and vice versa. A meta object may be invoked both explicitly and implicitly. Implicit invocation occurs at the transition of the object's state while the base-level object can invoke a meta object explicitly. The state transition diagram is shown in Figure s for Distributed Environments We have designed the following models: the Operation, Resource, Statistics, DE, Migration and System in the distributed environment. Those object models are depicted in Figure Operation The operational semantics of the programming language is the main concern in this model. In object-based programming language, the behaviors of objects consists of combination of primitive operations such as message sending, pushing to the evaluation stack and so on. In Operation, these primitive operations are dened. Level of Implementation Figure 3: Object for Distributed Environments A base-level object is represented by a meta object which consists of message queue, array of variables, state, and method table objects. Each state change of the baselevel object is expressed by interaction among those objects. Facilities for debugging and some hook mechanisms can be easily implemented in this model. For example, monitoring of message sending is realized by inserting the codes for monitoring(maybe print expression) to the semantics code of message sending. In such a sense, the operation model is the same abstraction of meta objects in computational reection languages such as 3-KRS[5] and ABCL/R[8]. In this model, all objects are location-independently accessed in the distributed environment Resource Resources in a local host such as memory and cpu are mainly concerned in this model. Resources related with the distributed environment such as network are not expressed. In the scheduler on the CPU, objects exists as context which have evaluation stacks, instruction pointers and so on. When the strategy of CPU scheduling is needed to change(for simple example, selecting FIFO or round robin strategy), objects must be handled as context objects. When we hope to change the strategy of garbage collectors, object have to be treat as segment objects in the main memory which have reference count and so on. The notion of an object is also employed but the representation of a base-level object diers from the Operation. Since the primary concern on this model is the management of resources, a base-level object is represented by a meta object which consists of segment and context objects. A segment object is an abstraction of 2

3 stop stop dormant bind cond reply self invoke terminate super ready activate terminate run invoke endmigrate endmigrate endmigrate beginmigrate beginmigrate beginmigrate req-sent rep-received endmigrate waiting invoke beginmigrate done migrate migrating Figure 2: State Transition Diagram of Our Object memory while a context object is an abstraction of the execution environment. Each state change of the base-level object is expressed by interaction among those objects. By modifying objects in this model, the CPU scheduling and garbage collection may be changed by a base-level object Statistics In the statistics model, an object is modeled by statistics information related to the object itself and underlying resources instead of procedural modeling. The statistics information of the base-level object includes cpu time, memory usage, and blocking time of communication while the statistics of underlying resources are load average, memory usage, communication usage, and so on. The scheduling priority in a local host and the strategy of the load balancing in the distributed environment is given by the constrains of the statistics information. A meta object in the statistics model keeps those statistics information. By the meta object programming in the statistics model, a base-level object may control the dynamic conguration in the declarative fashion, i.e., the constrains programming DE The DE (Distributed Environment) model is designed to abstract the distributed environment. Unlike the operation model, the location of an object and the information of remote hosts such as the CPU and communication load are visible in the DE model. The semantics of remote communication and migration is described by a meta object of the DE model. The meta object keeps the location of the receiver object and three special objects called nameserver, remoteinfo, and Network. Each state change of the base-level object is expressed by interaction among those objects to dene the semantics of remote communication and migration. The nameserver object is responsible for translating the unique identier (UID) of an object to the object address (or location), so that it has a cache table for the address translation. The strategy for updating the cache table is modied by changing the nameserver object. For example, we assume that the address translation table is only updated when an object is migrated into a remote host by default. By modifying the nameserver object, the strategy is changed so that the address translation table is updated only when remote communication fails due to the old object's address. The remoteinfo object keeps the hosts information such as the CPU and communication load. Using the information, we may control the load balancing strategy, i.e., the idle processor initiates the load balancing or the heavy load processor initiates the load balancing. The DE model enables us to modify the semantics of remote communication. For example, the call-by-move semantics introduced in Emerald[1] is easily implemented. The semantics of the call-by-move is that the caller object or the receiver object is moved into the receiver's host or the sender's host at the communication, respectively. The programmer must specify this semantics explicitly at programming of an application in Emerald. Contrast with Emerald, the advantage of the DE model is that the control of such a mechanism is separated in the base-level object programming and thus the programmer network-transparently writes an application. The programmer may control the semantics of remote communication during the optimization of the application phase without the modication of the base-level object. To describe the migration action, we need to have the ability of translating an object to a movable object which will be sent to the destination host. At the translation 3

4 to the movable object, it is better for us to express which other objects should also be moved at the migration. For example, consider the case that meta objects related baselevel objects must be moved with the base-level object. While there is the case that referenced objects as internal variables of objects have to migrated to. We want to decide which objects move together migrated object according to the properties of application. This semantics can not be described in the DE model because the lower level abstraction than the DE model is required to describe it. The migration model is designed to describe this nature Migration The migration model describes how an object migrates to a remote host. A base-level object is represented by a meta object which consists of a container object and the network object. The container object is the movable representation of the base-level object. When an object migrates to a remote host, the object is only moved by default. That is, even if the object keeps other objects, those objects are not moved. In order to decrease the communication trac, the base-level object can control which objects are moved to the remote host by the meta programming in the Migration model System All the semantics of primitive objects on the models above are dened in this model. An object is represented by a segment, semantics code, and evaluation stack. The segment represents an object which is the protected data so that the contents of an object are directly accessed. Contrast to the operation model, the semantics code on the operation model is concretely dened. 2.3 Benets of Multi- The benets of introducing multiple models to distributed environments are summarized. The meta levels which have multiple abstraction levels can be described. So we can program on various abstraction level. Users can select which model is most suitable for their programming according to properties of applications. Let us consider the programming about message sending. If the Operation is used, the location of objects in the system is transparent to programmers. While if we use the DE, the parts which search the destination of moved object by name server object can be customized. In the traditional programming language with features of meta-level programing, the abstraction level of the contents of meta levels is unique. Thus it is impossible to customize the behavior of objects on multiple abstraction level or to changed constituents which can be programed such as mentioning above. DE 1 DE 2 Mig suspend Host A Host B Host C (1) (3) (4) (6) migrationrequest ackmigrationrequest ackmigrationrequest migrationobject ackmigrationobject updatetable (2) (5) Figure 4: Object Migration Process As an example of the description of the distributed nature in our model, the object migration is described in the DE and Migration models. The Figure 4 depicts the scenario of the migration. (1) Host A sends the request of the object O's migration to other hosts in order to collect candidates of the destination. (2) When a host receives the migration request, it decides whether or not it accepts the O's migration. If the host can accept the object migration, an acknowledgment is sent to Host A. (3) Host A waits for any acknowledgments from other hosts. If Host A receives multiple acknowledgments, the most suitable destination is decided by the metaobject or the system. (4) Host A decides the destination of the O's migration, the object is copied to the destination. (5) When the system on the destination host receives the object, the system sends an acknowledgement of the migration to Host A. (6) When Host A catches the acknowledgment from the destination host, the system deletes O. Then the system on Host A sends all other hosts a message which tells other hosts to update the O's location. (2) 4

5 In Figure 4, the part DE 1 and DE 2 is described in the DE. That is, the meta object in the DE executes the (1), (2) and (3) operations if dened. While the part Mig is dened in the Migration. The meta object in the Migration executes the (4) operation if dened. 3 Object-Based Programming Language AL-1/D 3.1 Specication of the AL-1/D Programming Language Denition of Base-level Objects AL-1/D is an object-based programming language. The syntax of message passing is similar to the one of ConurrentSmalltalk[10] or Orient84/K[4]. But AL-1/D has no class hierarchy and supports for the delegation mechanism instead of the inheritance mechanism. An AL-1/D program consists of three parts: the denition of a base-level object, its meta objects and those methods. The following program is the example of a baselevel object declaration. 1 [ base Example 2 (deligations Object) 3 (vars var1 var2) 4 ] This base declaration denes a base-level object called Example which is a global name in a host. The statement delegations in line 2 denes destination objects for delegation of object Example. In this example, a message which is not understood in object Example is delegated to Object. In line 3, the statement vars denes the internal variables of Example: var1 and var2. A base-level object or a meta object is bound to an internal variable. The denition of methods and meta objects is separated from the base-level object declaration. The following example shows the denition of method factorial: which has one argument number. This method calculates the factorial value of an integer given by the argument and returns the value. After evaluating this program, method factorial: is added to Example and can be invoked by message factorial:. 1 [ method Example factorial: number 2 (vars i) 3 i = number; 4 if (i == 0) then 5 return 1 6 else 7 return i * (self factorial: (i - 1)) 8 end 9 ] An example of the message expression is shown below: obj selector: arg; obj selector1: arg1 selector2: arg2; This expression means that a message whose selector is msg and argument is arg is sent to receiver object. It should be noted that control statements such as if, while, and case are not realized by block objects and their interaction such like Smalltalk Creation of Objects There are two method for creating objects: Mentioned above, the declaration of the base-level object create objects. Using existing object as template objects, objects which have the behaviors same as template objects can be created. In later way, new objects are created by sending message create to the template objects. newobj = Example create; In above example, an object which has construction same as object Example is created and bound to variable newobj. In this case, object Example is called parent object of the newly created object, while new object is called child object of object Example. The child objects can create objects by receiving create messages. The parent objects is dierent from the destination object for delegation Denition of Meta Objects The denition of a meta object called MetaExample of the Example object is shown below. The meta object is dened in a model denoted by <MetaName> which must be replaced with one of Operation, Resource, DE, Statistics, Migration, and System. 1 [ meta <MetaName> MetaExample Example 2 (vars var1 var2) 3 ] After compiling this source code, the MetaExample object is registered as the meta object of the Example object. The meta object is referred to by all other objects, same as the base-level object. The internal variables and methods are dened as the same fashion of the base-level denition. The meta objects can create new objects as template objects samely as base-level objects. In this case, rst the meta objects are created without binding to baselevel object such as the below program. Next, the new object is created by sending message create to the object MetaExample. Finally the new object added to the meta table of base-level object Example by sending message addmeta:as to Example. The meta table is the table which holds related meta objects. In the below example, 5

6 the new meta object is created as the meta object in the Operation. 1 [ meta <MetaName> MetaExample 2 (vars var1 var2) 3 ] ameta = MetaExample create; 6 Example addmeta: ameta as: #Operation; The invocation of a meta object is restricted in three ways: a method is invoked i) only implicitly, ii) both implicitly and explicitly, and iii) explicitly. A method related with a state change of the base-level object is invoked implicitly or both implicitly and explicitly. In this paper, such a method is called a state method because the method is invoked when the state of the base-level object is changed. Most of state methods must run exclusively with other methods of the base-level object due to the base-level object state consistency but some state methods may run concurrently with other meta objects. In order to make such dierences clear, a state method which may concurrently run is denoted by a method name led by \!" while a state method which must exclusively run is denoted by a method name led by \!!" in this paper. 3.2 Denition of s The denition of Operation, Statistics, DE, Migration models are shown with the notation of AL-1/D language. The Resource and System models are not described in this paper. Those models were described in the previous our paper[2] Operation In the Operation, a base-level object is represented by message-queue, instance-variables, method tables, name tables, state of object, evaluation stack, continuation, sender object and template of future object. The following example shows the denition of a meta object named OpeExample which represents the Operation of base-level object Example. 1 [meta Operation OpeExample Example 2 (vars message_queue /* message queue */ 3 ivars /* instance variables */ 4 methodtable /* method table */ 5 nametable /* name table */ 6 state /* state */ 7 evaltop /* evaluation stack */ 8 continuation /* continuation */ 9 sender /* sender object */ 10 future /* future template */ 11 ) 12 ] Table 1 shows the list of semantics codes which represent the base-level objects in the Operation. In the AL-1/D system, these operation are dened as the semantics of the AL-1/D programming language. Table 1: Semantics Codes in Operation Method Name request:!!answer:from:!!ssend:message:!!asend:message:!!obind:value:!!tbind:value:!!reply:to:!!return:to:!!cond:true:false:!!self:!!super:!!methodbegin:!!methodend:!!stop:!!exception:!!timeout: Event request message arrival reply message arrival sync. message trans. expression async. message trans. expression binding an own variable expression binding a tmp variable expression reply expression return expression condition expression self expression super expression invoking a method terminating a method execution killed by G.C. exception occurs timeout occurs The default denitions of method!!ssend:message:, request: and!!obind:value: are shown below.!!ssend:message: represents the semantics of synchronous message sending. request: denes the event of reaching of message to receiver object.!!obind:value: represents the event which binds the value to internal variables. 1 [ method OpeExample!!ssend: rcvr message: msg 2 (rcvr meta: #request:) request: msg 3 ] 1 [ method OpeExample request: msg 2 msgqueue add: msg 3 ] 1 [ method OpeExample!!obind: pos value: val 2 ivars at: pos put: val 3 ] When any meta objects is dened explicitly, the default meta objects are dened which has above method. The message passing semantics is described in state method!!ssend:message: of the meta object in the Operation model. As shown in the following program, we are able to monitor the execution of the message sending operation by the modication of that method. 1 [ method OpeExample!!ssend: rcvr message: msg 2 Console print: "message "; 3 Console print: msg selector; 4 Console print: "is sent."; 5 Console printnl; 6 (rcvr meta: #request:) request: msg 7 ] Next example is the program which creates the meta object Example2 in the Operation. This meta object is created using object OpeExample as the template object. 6

7 1 [ method Example2 initmeta 2 (vars newmeta) 3 newmeta = OpeExample create; 4 Example2 addmeta: newmeta as: #Operation; 5 ] Statistics The behavior of a base-level object is expressed by statistic information of the object, constraints of these information, and algorithm for the satiser of these constraints in the Statistics. The following example shows the denition of a meta object named StatExample which represents the Statistics of the Example base-level object. 1 [ meta Statistics StatExample Example 2 (vars load /* load average of host */ 3 communication /* communication cost */ 4 cputime /* cpu time */ 5 memoryusage /* memory usage */ 6 blockingtime /* blocking time */ 7 ) 8 ] As shown below, constraints are dened in the constraint method of a meta object in the Statistics. A constraint is asserted by a message expression with a priority of the satiser. 1 [ method StatExample constraint 2 load lessthan: 1.23 priority: 1; 3 communication lessthan: 1.23 priority: 2; 4 cputime lessthan: 1.23 priority: 3; 5 memoryusage lessthan: 1.23 priority: 4; 6 blockingtime lessthan: 1.23 priority: 5; 7 ] The second line means that the limitation of load average is 1.23 and this constraint has priority 1(minimum priority). As default, constraint method has no boolean expression. So load balancing does not occur automatically. If method constraint is dened, AL-1/D system solves constraints in this method and controls object migration and so on. 1 [ meta DE DEShell6 Shell6 2 (parents nil) 3 (vars localhost nameserver remoteinfo network) 4 ] 5 6 [ method DEShell6!!ssend: rcvr message: msg 7 (vars rid rcvrlocation) 8 rid = nameserver location: rcvr; 9 rcvrlocation = rid host; 10 if (rcvrlocation == localhost) then 11 /* local send */ 12 (rcvr meta: #request:) request: msg 13 else 14 /* remote send */ 15 network send: rcvr message: msg host: rcvrlocation 16 end; 17 ] Figure 5: Program on the DE Let us realize the call-by-move semantics by the modi- cation of the default behavior. Figure 6 shows the new program giving the call-by-move semantics. In this program, if the receiver object exists on a remote host (line 6), the base-level object is moved to the remote host (line 7). The state statement in line 7 is to change a state to the migrating state. 1 /* another version for call-by-move */ 2 [ method DEShell6!!ssend: rcvr message: msg 3 (vars rid rcvrlocation) 4 rid = nameserver location: rcvr; 5 rcvrlocation = rid host; 6 if (rcvrlocation!= localhost) then 7 state migrating: rcvrlocation; 8 end ; 9 (rcvr meta: #request:) request: msg 10 ] Figure 6: Changed Program on the DE DE The distributed environment is recognized in the DE. The example shown in Figure 5 is the denition of the Shell6 object and its meta object named DEShell6 which represents the DE. The internal variables of DEShell6 are localhost, nameserver, remoteinfo, and network. The localhost variable keeps the location of the base-level object while the nameserver variable is bound to the NameServer object. As described in the previous section, the NameServer object is responsible for the object's address translation. The network variable keeps the Network object which handles remote message sending. The!!ssend:message: state method in Figure 5 species the default semantics of message massing. State method!beginmigration is shown in Figure 7. The method may be invoked by a meta object in the Statistics in order to satisfy the constraints. The!beginMigration method is responsible for nding the most suitable destination for the object and changing the current state to the migrating. As shown in the gure, the migration request message is sent to other hosts and a host which returns the maximum value(such as information of load average) is selected as the destination. The!beginMigration method executes the part DE 1 + DE 2 in Figure 4. By the meta programming of the!beginmigration method, we are able to modify the algorithm for nding the destination of migration. 7

8 1 [ method DEShell6!beginMigration 2 (vars destination host i max val nextvalue) 3 remoteinfo begin; 4 val = ValueList create; 5 num = 0; max = 0; 6 while (host = remoteinfo next) 7 val put: (host migraterequest: anobject &); 8 num = num end 10 for i = 0 step i = i + 1 to num do 11 nextvalue = val next; 12 if (val1 value > max) then 13 max = nextvalue value; 14 destination = nextvalue host 15 end 16 end 17 state migrating: destination; 18 ] Figure 7: Default Action on!beginmigration Migration Figure 8 shows the denition of a meta object named MShell6 which represents the Migration of the Shell6 object. The objlist keeps objects which are moved together with the base-level object. The meta object in this model has state method!!migrating: which executes the object migration. This method executes the part M ig in Figure 4. If users are willing to change the algorithm of migration, state method!!migrating is programmed. 1 [ meta Migration MShell6 Shell6 2 (parents nil) 3 (vars destination objlist bitstream) 4 ] 5 6 [ method MShell6!!migrating: dest 7 (vars nextlist) 8 /* base is migrated */ 9 Network write: bitstream to: dest; 10 nextlist = objlist; 11 while (nextlist!= nil) do 12 nextlist = nextlist next; 13 (nextlist value model: #Migration) migrate: dest 14 end 15 ] Figure 8: Program on the Migration Method!!migrating: writes the bit stream of the base-level object which is bound to the variable bitstream to the network. It also invokes objects bound to variable objlist in order to move those objects together. By default, the value in objlist is an empty list. In Figure 9, an example of modied method!!migrating: is shown. In the example, a meta object in the DE is moved together with the base-level object. 1 [ method MShell6!!migrating: dest 2 (vars nextlist newlist) 3 newlist = List create; 4 newlist value: base meta: #DE; 5 objlist append: newlist; 6 7 /* base is migrated */ 8 Network write: bitstream to: dest; 9 nextlist = objlist; 10 while (nextlist!= nil) do 11 nextlist = nextlist next; 12 (nextlist value model: #migrate:) migrate: dest 13 end 14 ] Figure 9: Changed Program on the Migration 3.3 Relationship among AL-1/D Objects There are some kinds of relationship among AL-1/D objects. These relationship is summarized here. base and meta This relationship is the one between base-level objects and meta objects. When any meta object is not dened explicitly, default meta objects are de- ned automatically. The six kinds of meta objects are used according to needed models. The meta object of the meta object can be created. Conceptually, innite tower of meta objects can be built. parent and child This relationship is the static relationship which is built when objects are created. The object as template is called parent object and the new object is called child object. Any changes of parent objects do not inuence child objects. For example, if a method is added to parents object, this method is not added to child object. The objects created without message create do not have parent objects. When child object are created, the meta objects of child objects are not created at the same time. This default action can changed by meta programming. delegatee and delegator This relationship is the relationship belong the object which delegates messages, called delegator, and the object which accept delegated message, called delegatee. The destination where messages delegate can be change dynamically. This change of destination is eect to the related meta objects in the Operation. These relationship is shown in the Figure 10. In this gure, object A2 is created from object A and object B is the destination where message which can executed in 8

9 object A2. The meta object OpeA is the meta of object A and have some meta objects of itself. method table ResA OpeA MigB B DeB message Deligatee(of A2) deligation StatD VM1 A send to B Network Handler return from B Network Handler VM2 Network Handler migration from VM3 send from A B return to A Network Handler Meta (of A) A create A2 message Network Handler Network Handler OpeA method table (shared) OpeC migration to VM2 Base (of OpeA) Parent(of A2) Deligator(of B) Child(of A) VM3 Figure 10: Relationship among AL-1/D objects Figure 11: AL-1/D System 4 Design and Implementation of AL-1/D system 4.1 Virtual Machine The AL-1/D system is implemented on a virtual machine(vm). Because we want to make implementation easy and this implementation is our rst step towards a exible system with reection facilities. The compiler translates AL-1/D source codes to bytecodes which are the instruction set of the virtual machine. The virtual machine runs in a host. Multiple virtual machines exist on several hosts connected with UNIX TCP/IP protocols. The virtual machine has some Network Handlers, each of which communicates with other virtual machines. When the virtual machines send remote messages or move objects, they put messages or objects into their Network Handlers(see Figure 11). The virtual machine of the AL-1/D system is programmed with C++. Conceptually, the behaviors of all AL-1/D objects are dened by their meta objects. If no meta object of the base-level object is dened, default meta object is created automatically. The default meta objects are not executed by the virtual machine but the behavior of the virtual machine itself. The denition of the virtual machine is the denition of the default meta objects of all AL-1/D objects. 4.2 Issues on Realization of AL-1/D Systems In our object model, a base-level object and some meta objects are running independently. However when these objects are realized on the virtual machine, they may send messages to each other. This action of objects causes in some problems about synchronization among objects. Such problems are described below Synchronization Among Meta Objects Because all objects may run concurrently and a base-level object has multiple meta objects, those meta objects may run concurrently. However, some meta objects may not run while other meta objects are running at the same time. As described in section 3, a state method led by \!" may concurrently run while a state method led by \!!" must exclusively run with other meta objects of the baselevel object. The compiler creates the codes for the suspend and resume operations when it nds a meta method which must exclusively run with other metas. In concurrent programming, one of the most important issues is avoiding deadlock. In AL-1/D, some meta object of the same base-level object may be active, the deadlock occur among these meta objects. The AL-1/D system supports no mechanism for avoiding deadlock. Then programmer must program carefully by state methods in order to keep away from occurring deadlock. 9

10 4.2.2 Invocation of Meta Objects When a meta object is invoked, reication occurs. When the execution of a meta object is done, reection occurs. In order to realize these operations, the system needs to distinguish whether or not an object is meta. There are two means of the distinction; 1. Each object has a ag for distinction whether it is a meta object of not and the bytecode interpreter handles the operation of reication and reection at running time. 2. bytecodes for reication and reection are inserted by the compiler at compiling meta methods. In the rst method, there are more overheads at the run time because the bytecodes interpreter needs to check the ag on every time of message sending. Considering the overhead of the bytecode interpreter on sending messages, we adopt the second method. Thus, the compiler has information for models, and create reication codes at the begging of methods and reection codes at the end. These codes are described in the next subsection. 4.3 Bytecodes The bytecodes used in the AL-1/D system are similar to the ones used in ConcurrentSmalltalk[10]. However, considering above discussions, new some bytecodes are introduced in order to support reection facilities Retrieve Bytecode The retrieve bytecode is the instruction of the reication operation. At the beginning of all methods of a meta object, the retrieve bytecode is generated by the compiler. The retrieve bytecode binds components of the base-level object to variables of meta object according to the kind of the meta object Unretrieve Bytecode The unretrieve bytecode is the instruction of the reection operation. The compiler inserts the unretrieve bytecode before generating the return bytecode in all methods of a meta object. The unretrieve bytecode makes changes by a meta object reect to the base-level object. Considering the performance, only variables changed by the meta object are bound to variables of the base-level object. 4.4 suspendmetas and resumemetas bytecodes The suspendmetas and resumemetas bytecodes are designed in order to avoid the inconsistency of the internal state of objects on the invocation of a meta object. The suspendmetas bytecode suspends the execution of all metas of the base-level object by force while the resumemetas bytecode resumes the execution of the baselevel object. 5 Evaluation The AL-1/D system is evaluated in this section. The AL- 1/D system is implemented on Sun SPARCstations and DECstations connected by the Ethernet. The following results of the evaluation are based on the old AL-1/D system on Sun SPARCstation 2's in which the interpreter always translates a base-level object into the representation of a meta at the reication operation, and vice versa at the reection operation. 5.1 Basic Performance Overheads of Invocation of Meta Objects We show overheads caused by the invocation of meta objects. The cost of a simple invocation of a meta object representing the DE or Migration is measured. The result is shown in the Table 2. In the new version of AL-1/D system, we expect the overheads of invocation of meta objects is reduced by 50%. Table 2: Invocation time of meta objects kind time(msec) Operation 2.13 DE 0.78 Migration 0.64 DE + Migration Performance of Communication We measure the cost of communication. three types of communication: (i) local send: same host. We evaluate Both sender and receiver exist on the (ii) remote send: Receiver exists on dierent host from the host where the sender exist. The location of the receiver is already known. (iii) search location & remote send: At rst the virtual machine searches the location of receiver. Since the message for searching is needed, there are two roundtrips of messages. In each case, the program for evaluation of message sending is the below program. In this program, object TestSend send synchronous messages to object One 10,000 times. 10

11 1 [ method TestSend start 2 (vars limit i) 3 limit = 10000; 4 while (i < limit) do 5 One value; 6 i = i end 8 ] 9 10 [ method One value 11 return 1 12 ] For comparison, we measure the time of sending a packet on the UNIX stream whose size is the same as the packet on remote sending. The local sending time is the round-trip time when an object invokes another object which just returns value 1 and receives the return value. The result is shown in the Table 3. Table 3: Communication time in the AL-1/D time(msec) (i) local send 0.03 (ii) remote send 2.21 (iii) location/remote send 4.47 UNIX stream 1.53 Next, the time of the object migration is measured. For the measurement, the Shell6 object is moved to another host when the object is not running. The object has ve methods and no any internal variables nor meta objects programmed by users. We also measure the time of sending a packet by the UNIX stream for the comparison. The packet is the same size of a packet on the migration. The result is shown in the Table 4. Table 4: Migration time in the AL-1/D time(msec) Object Migration 5.63 UNIX stream 2.25 The result shows that object migration is ecient when messages are only sent to the same remote object more than three times AL-1/D vs ConcurrentSmalltalk We compare the performance of the AL-1/D system with the one of the ConcurrentSmalltalk(CST)[10] system since CST is a concurrent object-based programming language system and running under the similar virtual machine without the reection facilities. Table 5 shows the comparison about the speed of local message sending between AL-1/D and CST. We execute an application in which an object sends a message 10,000 times to another object which returns 1. The time of local sending is the measured time divided by 10,000. The result is shown Table 5. Table 5: Comparison between AL-1/D and CST System local send time(sec) AL-1/D 0.03 ConcurrentSmalltalk 0.02 The result shows that the performance of the AL-1/D system is little lower than ConcurrentSmalltalk. This difference is due to the dierence of the implementation languages: C and C++. This concludes that we realized the reasonable performance for a concurrent object-oritened programming language with reection facilities. 5.2 Comparing between the Default Execution of the VM and the Execution with Reection When we do not dene meta objects, the behavior of the base-level object is realized by the virtual machine in the AL-1/D system. We evaluate the dierence of the execution speed between the default behavior and the behavior changed by meta objects. We compare the default execution of DE1, DE2 and Mig in Figure 4 with the execution of the same operation dened in meta objects programmed by the user. The result is shown in Table 6. The legend of the rst column is the following: (i) The default execution of the VM The default execution time of the virtual machine without programming meta objects. The virtual machine (VM) searches a place where the object should move and then the object is moved to the place. (ii) The trace of the default action by meta objects The execution time of the same operation of the default action programmed in meta objects. This is the result of execution of the sample program shown in the Figure 7 and 8. The meta object in the DE searches the place where the base-level object should be moved and the then meta object in the Migration moves the base-level object. The result is the total time in which the meta objects in DE and Migration. (iii) The execution after change The meta object in the Migration is modied so that the user-dened meta objects are also moved. This is the result of execution of the sample program shown in Figure 7 and 9. Because of changing the behavior of the meta object in Migration, the code size is increased. 11

12 Table 6: Execution time of the VM and meta objects time(msec) ratio to (1) dierence from (1)(msec) number of messages number of codes (i) (ii) (iii) The result shows that it takes 5.7 times much than the virtual machine to move the object by the meta object. As much as we change the denition of the Migration, it takes much time to move an object since the size of the compiled code becomes larger. It is important to show such values to users when he needs to decide customizing of the behavior or decreasing of running time. 6 Conclusion In this paper, we proposed the new object model with re- ection in order to construct a exible distributed system. The distributed programming language system: AL-1/D is designed and implemented based on this model. The AL-1/D is a concurrent object-based language which provides facilities of remote communication and reection. By employing the Multi- Reection Framework two levels are introduced in the distributed environment, i.e., the network transparency level and the distributed environment level. The Operation model is dened as if all objects exist on a single host in the network transparency level. The DE and Migration models are dened to describe the behavior of the distributed environment in the distributed environment level. In AL-1/D, the users have the rights to select which model is suitable for understanding the system as well as modifying the object behavior. The AL-1/D system runs on SPARCstations and DECstations connected with the Ethernet. Comparing with a concurrent object-oriented programming language system, we conclude that the reasonable performance is achieved without sacricing the performance of faculties for concurrent object-oriented programming in the AL- 1/D system. There are some reective systems on distributed environments: Apertos [9] and ABCL/R2[6]. The dierence among AL-1/D and these systems is described below. Muse OS is an operating system on which the behavior of components can be changed. The abstraction of meta objects in Muse OS might be the same as the Resource in AL-1/D. Since a programming language on Muse OS is being developed, we can not compare the language with the AL-1/D. ABCL/R2 introduced the concept of groping for adapting the distributed environment. The group seems to represent one host or domain in network. It is similar to Operation and DE in AL-1/D. Since the grouping concept is highly abstracted, the concrete behavior in the distributed environment can not be described, e.g., network trac and delay. Thus, it is dicult to congure dynamically the system by using the concrete behavior unlike AL-1/D. Finally, we mention our future works. improving reication speed It is obvious from results of evaluation that it takes much time to invoke meta objects. The reason is that much information of base-level objects are bound to meta object in the reication time. All information, however, not used in one invocation. We have a plan that the implementation of reication is improved. In the new implementation, information is not bound to meta objects at invocation time but bound to at rst accessing to this information. supporting of \meta language" In the current status, models are statically dened. More exible system needs the facility for dening models by users. In order to dene new models, we are planning to provide a \meta language". without virtual machine We have a plan of the implementation including an operating system or the implementation on an operating system with reective architecture such as Muse OS. References [1] Andrew Black, Norman Hutchinson, Eric Jul, and Henry Levy. Object Structure in the Emerald System. In Proceedings of ACM OOPSLA'86, [2] Yutaka Ishikawa. Reection Facilities and Realistic Programming. Sigplan Notice, 26(8), August [3] Yutaka Ishikawa and Hideaki Okamura. A new Re- ective Architecture: AL-1 Approach. In Proceedings of OOPSLA'91 Workshop on Reection and Metalevel Architectures in Object-Oriented Programming, October [4] Yutaka Ishikawa and Mario Tokoro. Concurrent Programming in Orient84/K: an Object-Oriented Knowledge Representation Language. In Proceedings of ACM OOPSLA'86,

13 [5] Pattie Maes. Concepts and Experiments in Computational Reection. In Proceedings of ACM OOP- SLA'87, pages 147{155, [6] H. Masuhara, S. Matsuoka, T. Watanabe, and A. Yonezawa. Object-Oriented Concurrent Reective Languages can be Implemented Eciently. In Proceedings of ACM OOPSLA'92, October [7] Hideaki Okamura, Yutaka Ishikawa, and Mario Tokoro. Towards building the exible systems on distributed environments. In OOPSLA'91 Workshop on Reection and Metalevel Architectures in Object- Oriented Programming, October [8] Takuo Watanabe and Akinori Yonezawa. Reection in an Object-Oriented Concurrent Language. In Proceedings of ACM OOPSLA'88, pages 306{315, [9] Yasuhiko Yokote. The Apertos Reective Operating System: The Concept and Its Implementation. In Proceedings of ACM OOPSLA'92, pages 414{434, October [10] Yasuhiko Yokote and Mario Tokoro. The Design and Implementation of ConcurrentSmalltalk. In Proceedings of ACM OOPSLA'86, pages 331{340,