Compilation of a Highly Parallel Actor-Based Language WooYoung Kim?and Gul Aghay Department of Computer Science University of Illinois at Urbana-Champaign Urbana , IL 61801 , USA Email : fwooyoung j aghag@cs.uiuc.edu June 23 , 1992 Abstract Hal incorporates a number of high-level language constructs such as the incremental specialization of synchronization constraints to maintain the consistency of actors at run-time , the inheritance of both code and synchronization constraints , and limited reflective capabilities to customize the system with respect to fault tolerance . This paper describes some issues in compiling Hal , and , in particular , three source level transformations used by the compiler for Hal . Two of the transformations translate RPC-style message sending into asynchronous message sending . The third transformation performs code motion to optimize the implementation of replacement behavior . This optimization results in the reduction of object code size as well as execution time . yThe work described in this paper has been made possible by generous support provided by a Young Investigator Award from the Office of Naval Research -LRB- ONR contract number N00014-90-J-1899 -RRB- , by an Incentives for Excellence Award from the Digital Equipment Corporation , and by joint support from the Defense Advanced Research Projects Agency and the National Science Foundation -LRB- NSF CCR 90-07195 -RRB- . 1 Introduction A number of efforts have been made to build parallelizing or vectorizing compilers which attempt to extract parallelism from code written in traditional sequential programming languages such as FORTRAN -LSB- 26 , 5 , 27 -RSB- . Others have concentrated on compiling specialized languages which are inherently concurrent , such as functional languages -LSB- 18 -RSB- and Data Flow -LSB- 7 -RSB- . Unfortunately , such languages are inadequate to model concurrency in a state-based , nondeterministic world -LSB- 1 -RSB- . A third language paradigm consists of languages which explicitly manipulate parallelism . Some examples are CSP -LSB- 9 -RSB- and Occam -LSB- 25 -RSB- . However , CSP and Occam have an unavoidable limitation in the sense that a process in these systems can not create a new communication channel at run-time or pass it to another process . The configuration of the system is fixed at compile time resulting in a static topology . Our work is related to the last two paradigms . We use the Actor model -LSB- 1 -RSB- which unifies the functional and the object-based view of computation , supports parallelism explicitly and provides for a dynamic topology of computational agents . On the other hand , the Actor model differs from the model used in LINDA -LSB- 11 -RSB- , which separates coordination from computation rather than treats them in a single framework . We have developed a high-level programming language , called Hal . Our goals in designing Hal are as follows : Generality : We want our programming language to be truly general purpose . Control parallelism as well as data parallelism should be expressed in Hal in a natural way . Shared objects should be easily described . Furthermore , Hal should be architecture independent to allow efficient execution on both shared and distributed memory machines . Modularity and Abstraction : To simplify programming , Hal should support data and functional abstraction . In particular , users should be able to specify the abstraction -LRB- interface -RRB- independently of its representation -LRB- implementation -RRB- . Furthermore , Hal should support re-usability through language constructs such as inheritance , higher-order functions and reflection . Efficient Execution : It should be possible to describe arbitrary applications in sufficient detail to support efficient execution on different concurrent architectures . In particular , the same application may require different resource management techniques on different concurrent architectures . In designing Hal , we use a reflective Actor model to realize those goals . The current paper describes ongoing work on Hal and its compiler . Compiling Hal for efficient execution creates a number of distinct problems . We describe some of these problems , namely , resource management , inherent concurrency , synchronization constraints and distributed objects . These problems stem from the power and the flexibility inherent in actor-based languages . Resource Management Hal is designed in such a way that the code of a parallel algorithm can be described in an architecture independent way . However , for efficiency it is often essential to explicitly specify resource management policies for actor placement and load balancing . Hal allows the code for resource management and code for the application to be separately specified . Besides reducing code complexity , this allows both the code of application algorithms and the code for resource management strategies to be reused . The compiler must combine these two kinds of specifications for efficient execution -LRB- Section 2.7 -RRB- . Inherent Concurrency The Actor model supports internal concurrency as well as explicit parallelism -LSB- 1 -RSB- . The internal concurrency is inherently fine-grained . However , almost every conventional processor is too coarse grained to realize the fine-grained computation inherent in the internal concurrency in an efficient way . To achieve better performance , we must have a certain amount of run-time control over grain size . The internal concurrency makes it possible to pipeline behavior changes of an actor . However , the implementation of such pipelining on coarse grained processors carries memory management overhead . By not implementing such pipelining , we have obtained a good performance improvement on current generation medium-grained multicomputers . -LRB- Section 3.2 -RRB- . Representation of method invocations in the form of functional expressions allows the simple specification of control in the program . Unfortunately , it can cause unnecessary loss of concurrency if a function caller blocks until it receives returned function value . The transformation of such representations into asynchronous message passing makes it possible to retain maximal concurrency in the program -LRB- Section 3.1 -RRB- . Synchronization Constraints In a CSP like model , communicating processes must be synchronized whenever they exchange messages with each other . The synchronization is accomplished through busy waits . Synchronous communication is expensive because that a sender can not send a message until a receiver is ready to accept the message , causing loss of concurrency . In contrast , by using buffering accompanied with asynchronous message passing , we eliminate the need for extraneous synchronization , thereby , retaining the concurrency . Furthermore , asynchronous communication localizes the enforcement of synchronization constraints at the recipient . This is especially important since a requirement of fairness requires the re-evaluation of synchronization constraints with each message and state change -LSB- 14 , 15 -RSB- . Distributed Objects If only one actor is responsible for processing all incoming communications to a large data structure , the actor will be a bottleneck . We avoid the single address bottleneck problem associated with the uniqueness of an actor 's address by allowing concurrent access to a large data structure and locking only the relevant portion of the data structure . Our approach follows work on Concurrent Aggregates -LSB- 12 -RSB- . In the following section , we discuss some linguistic features of Hal with their semantics . Section 3 discusses the transformations of RPC style message sending and the transformation for code motion to optimize the implementation of replacement behavior . Some research related to our compiler is described in Section 4 . The last section provides future research directions and concluding remarks . 2 HAL : A High-level Actor Language We begin the section with a brief description of the Actor model . We then discusses the specification of synchronization constraints , inheritance , and the specification of replacement behavior . Finally , issues related to memory management , extensions to the asynchronous message passing primitive and reflection capability are addressed in that order . 2.1 The Actor Model Actors are self contained , independent computational agents that communicate by asynchronous message passing -LSB- 1 -RSB- . An actor consists of its mail queue and behavior . It is identified by its unique mail address . The mail queue of an actor buffers incoming communications -LRB- i.e. messages -RRB- . The behavior of an actor specifies the action performed by an actor in response to a communication . An actor 's state is defined by its acquaintances -LRB- actors whose mail addresses are known to the actor -RRB- . All computation in an actor system is carried out in response to communications sent to actors in the system . Specifically , an actor may perform three kinds of actions when it accepts a message : ffl it may change its behavior . ffl it may send more communications . Communication is asynchronous and point-to-point to an acquaintance . The sender may not be known , but the recipient must be an acquaintance of the sender . The delivery of a message is guaranteed after an arbitrary , but finite , delay -LRB- a fairness condition -LSB- 14 -RSB- -RRB- . ffl it may create more actors . These actors have their own unique mail addresses which are initially known only to their creator and possibly themselves . The replacement behavior of an actor is specified through the become primitive . Whenever there is no executable become primitive in the thread of an actor computation , an identically behaving actor is assumed to be its replacement behavior -LRB- by default -RRB- . Note that communications may contain mail addresses of actors ; thus the interconnection topology of an actor system is dynamic . Building on the basic actor execution model , we have designed a high-level programming language , named Hal -LSB- 16 -RSB- . Hal is a descendant of actor languages such as Acore -LSB- 24 -RSB- , Rosette -LSB- 30 -RSB- and ABCL/R -LSB- 33 -RSB- . It provides abstractions which facilitate software development . We describe the constructs used for such abstractions below , emphasizing implementation issues . A more detailed description of the language constructs and their motivation may be found in -LSB- 16 , 17 -RSB- . Note , however , that Hal is an evolving language . New high-level constructs are continually being developed and tested in order to explore ways of simplifying the task of parallel programming while improving efficiency in execution . 2.2 Specification of Synchronization Constraints Actor semantics does not require message order preservation . In order to protect the system as well as an actor from possible internal inconsistency due to message order nondeterminism , we need to be able to specify synchronization constraints on actors . Earlier work has established how synchronization constraints can be used for software pipelining -LSB- 3 -RSB- . In particular , such pipelining transforms some algorithms , such as the Cholesky Decomposition of a symmetric positive definite matrix , from unscalable algorithms into scalable ones . We have adopted a philosophy of synchronization constraints proposed in -LSB- 15 -RSB- . All constraints are expressed as disabling restrictions . A disabling restriction means whenever any condition associated with a method evaluates to TRUE , the underlying system closes the entry point of the method and disables the method . All messages with the method name are not accepted until all conditions evaluate to FALSE . Use of disabling restrictions instead of enabling conditions -LSB- 30 , 6 -RSB- ensures that the synchronization constraints which hold for a superclass also hold for the subclasses which are derived from the superclass . Therefore , programmers can reason about the subclasses in terms of the superclass -LSB- 15 -RSB- . Disabling restrictions are specified using the following syntax : -LRB- disable <msg-expr> <expr> -RRB- -LRB- all-except <msg-expr> <expr> -RRB- where <msg-expr> specifies the method name on which the constraint is imposed . Users are allowed to associate more than one synchronization constraint with a method . <expr> is a function of acquaintances -LRB- i.e. actor 's internal state -RRB- and the incoming communication . When <expr> evaluates to TRUE , the method specified in <msg-expr> is disabled . If a constraint is specified with all-except , all other methods are disabled except one specified in <msg-expr> . The incoming messages with the method name are kept in the actor . When all conditions associated with a method evaluate to FALSE , its entry point is open and the pending messages may be processed . A potentially significant source of inefficiency is the need to re-evaluate the constraint expressions of the pending messages that are kept in an actor . In the current implementation , whenever the actor state changes , all constraints associated with the pending messages are re-evaluated . To allow more efficient execution , we are currently experimenting with a scheme which requires the evaluation of only those constraints that depend on the acquaintances which have changed . Specifically , our scheme uses dynamic dependency lists between an actors acquaintance and constraints . 2.3 Inheritance Hal has been designed to satisfy all of Wegner 's qualifications to be classified as an object-oriented language -LSB- 34 -RSB- . Class variables are not supported since they imply shared data between actors , thus restricting their autonomy and distribution . Hal allows the inheritance of both code and synchronization constraints . As in Smalltalk -LSB- 22 -RSB- , any method of the superclass of an actor may be redefined in the definition of the actor . Synchronization constraints , however , may only be strengthened , not weakened -LSB- 15 -RSB- . In this sense , inheritance can be viewed as a means of specialization . However , we are investigating whether it is beneficial to allow first-class constraints . Figure 1 defines a set of stack classes which exemplify the possible usage of inheritance and synchronization constraints . The most basic actor class is Stack which has the methods to push and pop one element to and from the stack , respectively . This definition has a constraint -LRB- > count 0 -RRB- on pop which must hold in order for a pop message to be processed . The Bounded-stack class is a subclass of Stack . This class has a constraint on the absolute size of the stack ; one can not make the stack hold more than max elements at any time . Since we -LRB- defActor Stack -LRB- stack count -RRB- -LRB- disable -LRB- pop -RRB- -LRB- < count 0 -RRB- -RRB- -LRB- method -LRB- push x -RRB- -LRB- update stack -LRB- cons x stack -RRB- -RRB- -LRB- update count -LRB- + count 1 -RRB- -RRB- -RRB- -LRB- method -LRB- pop entrypoint continuation -RRB- -LRB- send entrypoint continuation -LRB- car stack -RRB- -RRB- -LRB- update stack -LRB- cdr stack -RRB- -RRB- -LRB- update count -LRB- - count 1 -RRB- -RRB- -RRB- -RRB- -LRB- defActor Bounded-stack -LRB- max -RRB- -LRB- superclass Stack -RRB- -LRB- disable -LRB- push -RRB- -LRB- > count max -RRB- -RRB- -RRB- -LRB- defActor Pop2-stack -LRB- superclass Bounded-stack -RRB- -LRB- disable -LRB- pop2 -RRB- -LRB- < count 1 -RRB- -RRB- -LRB- method -LRB- pop2 entrypoint continuation -RRB- -LRB- send entrypoint continuation -LRB- car stack -RRB- -LRB- car -LRB- cdr stack -RRB- -RRB- -RRB- -LRB- update stack -LRB- cdr -LRB- cdr stack -RRB- -RRB- -RRB- -LRB- update count -LRB- - count 2 -RRB- -RRB- -RRB- -RRB- Figure 1 : Stack actor classes have separated the specification of synchronization constraints from the code of the actual method , we only need to state the new constraint without having to redefine the push method . Note that more restrictions are imposed on the push method in Bounded-stack class than in Stack class . Finally , we define the Pop2-stack class as a subclass of the Bounded-stack class with the ability to pop two elements out of the stack as an atomic action . This behavior is provided through the pop2 method . Under our constraint specification scheme , the definition of both pop and push methods can be inherited from the Stack class into both of these subclasses . Also , the incremental specialization of synchronization constraints is allowed through inheritance -LSB- 15 -RSB- . 2.4 State Change Replacement behavior is computed by the become primitive in the Actor model . An actor can become an entirely different actor as a result of processing the become primitive . However , in many cases , replacement behavior involves only one or two acquaintance changes of an actor . The update primitive gives us a convenient way to specify a replacement behavior with the change of one acquaintance . It has the following syntax : -LRB- update <acquaintance-name> <expr> -RRB- update obeys a single-assignment semantics : there may be only one become in any given method invocation . However , more than one update can appear if they do not update the same acquaintance . Since the effect of replacement behavior is invisible to the current computation of an actor , multiple update 's can be viewed as one become with several acquaintance changes . 2.5 Message-passing Mechanisms Besides the asynchronous message sending provided in Actor semantics , Hal provides two more message sending primitives : ssend and bsend . The former is the message order preserving send primitive , or sequenced send . The latter is the RPC style send primitive akin to Acore 's ask primitive -LSB- 24 -RSB- . Though they have some flavor of synchronous message sending , they are not synchronous in the sense that a sender does not need to know whether a receiver is ready to accept its message or not . ssend gives a sender a way to control the sequence of actions which occur at a receiver . bsend is just like a function call so that the computation proceeds with the reply from the receiver . ssend is implemented by tagging the message sent and reordering messages , if needed , at the recipient 's end . bsend can be used as a way to synchronize several coordinating actors . The implementation issues related to bsend are given in detail in Section 3.1 . 2.6 Suicide When executing a large actor program , many actors may be created as a result of computation . Some of them will never be used again after they have accepted certain communications . Once they process particular communications , they become garbage actors , wasting valuable resources until they are reclaimed by garbage collector . It is beneficial to reclaim the resources which belong to such actors as soon as they become garbage . suicide is the primitive which does exactly what we want . It is similar to that used in Cantor -LSB- 8 -RSB- . When an actor executes the suicide primitive , it frees all the resources which are allocated to it so that the resources can be reused . This primitive can be used by a programmer or the compiler . Readers can find an example for the latter case in Section 3.1.1 . Once garbage collection has been fully optimized , use of suicide would be discouraged since suicide creates unsafe programs . 2.7 Reflection Reflection is a system 's ability to reason about itself and manipulate a causally connected description of itself -LSB- 28 , 23 -RSB- . Causal connection means that changes to the description have an immediate effect on the described object . Note , however , that the changes go into effect only for the subsequent messages . In general , reflection may be used to customize the implementation of a system from within the language . Currently , Hal supports the minimal amount of reflection capability necessary to customize the system with respect to fault tolerance -LSB- 2 -RSB- . An actor can reify its dispatcher and mail queue -LRB- the conceptual entities responsible for sending and receiving the communication , respectively -RRB- . -LRB- Mailq <expr> -RRB- -LRB- Dispatcher <expr> -RRB- The value of <expr> is the mail address of an actor . Once the mail queue of an actor is reified , all subsequent messages destined to the actor are delivered through its reified mail queue actor . To get a next message to process , the actor notifies its reified mail queue actor by sending a special message . A synchronization constraint is associated with the method in the mail queue actor corresponding to the message , guaranteeing that the message is accepted only when the mail queue actor has one or more messages to deliver . Reification of the dispatcher of an actor causes all the outgoing messages from the actor to be sent through its reified dispatcher actor . These are implemented by using system-generated put , get and transmit messages , respectively . Since reified mail queue actors and reified dispatcher actors are just ordinary actors , we can use any actor as a mail queue actor or a dispatcher actor . However , our implementation requires that all mail queue actors share a set of common properties such as having put and get methods , being able to hold the incoming messages in its state , etc. . The dispatcher actors share their own common properties too . We enforce these rules by restricting the eligible actors for mail queue actors or dispatcher actors : the run-time system provides the default mail queue/dispatcher actor classes from which all the other mail queue and dispatcher actors inherit , respectively -LRB- Figure 2 -RRB- . Users can define a mail queue actor class as follows : -LRB- defActor myMailQ -LRB- acq1 acq2 -RRB- -LRB- superclass Mailq -RRB- -LRB- method -LRB- entry1 a b c -RRB- : A dispatcher actor can be defined similarly . The compiler enforces all mail queue -LRB- dispatcher -RRB- actors to have the default Mailq -LRB- Dispatcher -RRB- actor class at the top of its class hierarchy . Similarly , for the dispatcher actors . Note that a user does not need to know about the existence of enqueue , dequeue and toss shown in Figure2 . enqueue adds a message to the queue internal to a mail queue actor . dequeue -LRB- defActor Mailq -LRB- baseActor queue -RRB- -LRB- disable -LRB- get -RRB- -LRB- emptyqueue queue -RRB- -RRB- -LRB- method -LRB- put msg -RRB- -LRB- enqueue queue msg -RRB- -RRB- -LRB- method -LRB- get -RRB- -LRB- let -LSB- -LSB- msg -LRB- dequeue queue -RRB- -RSB- -RSB- -LRB- toss msg baseActor -RRB- -RRB- -RRB- -RRB- -LRB- defActor Dispatcher -LRB- method -LRB- transmit msg dest -RRB- -LRB- toss msg dest -RRB- -RRB- -RRB- Figure 2 : Default mail queue actor class and default dispatcher actor class returns the message at the front of the queue . toss is just a variation of send , the asynchronous message sending primitive but it uses an already packed message so that it saves unnecessary unpacking and packing of the message . These reflection capabilities have been used to carry out an experiments in implementing reusable software fault tolerance protocols -LSB- 2 -RSB- . Such capabilities can also be used to separate the code for resource management , such as that for optimal actor placement , from the code for an application . 3 Implementation Issues In this section , we discuss three transformation techniques used in the Hal compiler . Two transformations allow translation of RPC style send primitives into asynchronous send primitives . The last one is the transformation for code motion to optimize the implementation of update / become primitive . The transformed programs shown in the figures are written in Hal itself to make it easier to understand the meanings of the transformations . 3.1 Transformation on RPC Style Send Primitive Most distributed memory multi-processor systems do not support truly synchronous message sending in the sense that a sender and a receiver can not synchronize with each other when they exchange a message . In order to implement RPC style message sending -LRB- Section 2.5 -RRB- on such architectures , we must be able to express it in terms of ordinary asynchronous message sending . In the following two sections , we discuss the implementation of RPC style message sending in our compiler . 3.1.1 Join Continuation Recall that bsend is like a remote procedure call which returns a result back to the place where the call is made . By lifting into a separated actor the expressions that should be executed only after a bsend expression receives a reply . we can implement bsend in terms of send . Note that the lifted actor is the continuation of the bsend expression . Delegation of work to an independent continuation actor makes it possible to avoid unnecessary loss of concurrency in the execution . -LRB- send mB -LRB- new ActorB a b -RRB- x -LRB- bsend mC ActorC ... -RRB- -LRB- bsend mD ActorD ... -RRB- -LRB- bsend mE ActorE ... -RRB- -RRB- Figure 3 : Example expression which uses bsends Consider the expression in Figure 3 . The send expression has no effect on the computation of the other parts of the method script except that it should be executed only after it gets all the replies from the bsend expressions . Simply making the continuation passing style -LRB- CPS -RRB- conversion -LSB- 29 , 21 -RSB- is not satisfactory since it sequentializes the execution of the bsend expressions , causing a loss of concurrency . We create an independent join continuation actor through dependency analyses . The expression in Figure 3 is transformed into the join continuation actor in Figure 4 and the expression in Figure 5 . The join continuation actor is responsible for the execution of the expressions that must be executed only after all replies arrive from the target actors of the bsend expressions . When the join continuation actor gets a reply from one of target actors , it checks if all the other values have been received . If so , it executes the assigned expressions . If not , it stores the value in its state and waits until all values are available . The availability of each value is kept in a flag which is associated with the corresponding acquaintance variable . In Figure 4 , a join continuation actor is created with the appropriate initial values for its acquaintance variables and the environment in which it executes the assigned expressions . Note that a unique method name corresponding to the entry point of each reply message as well as the join continuation actor is added in the original bsend expressions . The definition of receiver actors should be modified accordingly to reflect the change in the sender actor 's definition . -LRB- defActor JC -LRB- acq1 acq2 v1 v2 v3 f1 f2 f3 -RRB- -LRB- method -LRB- ep1 x -RRB- -LRB- if -LRB- and f2 f3 -RRB- -LRB- block -LRB- send mB acq1 acq2 x v2 v3 -RRB- -LRB- suicide -RRB- -RRB- -LRB- block -LRB- update v1 x -RRB- -LRB- update f1 TRUE -RRB- -RRB- -RRB- -RRB- -LRB- method -LRB- ep2 x -RRB- -LRB- if -LRB- and f1 f3 -RRB- -LRB- block -LRB- send mB acq1 acq2 v1 x v3 -RRB- -LRB- suicide -RRB- -RRB- -LRB- block -LRB- update v2 x -RRB- -LRB- update f2 TRUE -RRB- -RRB- -RRB- -RRB- -LRB- method -LRB- ep3 x -RRB- -LRB- if -LRB- and f1 f2 -RRB- -LRB- block -LRB- send mB acq1 acq2 v1 v2 x -RRB- -LRB- suicide -RRB- -RRB- -LRB- block -LRB- update v3 x -RRB- -LRB- update f3 TRUE -RRB- -RRB- -RRB- -RRB- -RRB- Figure 4 : Extracted Join Continuation actor The transformation given in this section is similar to the transformation done in Acore -LSB- 24 -RSB- . -LRB- let * -LSB- -LSB- jc -LRB- new JC -LRB- new ActorB a b -RRB- x FALSE FALSE FALSE -RRB- -RSB- -RSB- -LRB- send mC ActorC ... ep1 jc -RRB- -LRB- send mD ActorD ... ep2 jc -RRB- -LRB- send mE ActorE ... ep3 jc -RRB- -RRB- Figure 5 : The transformed expression ActorAActorBActorCActorDActorEJC Figure 6 : Message trajectory after extracting the Join Continuation actor However , there are two major differences . First , by associating with each acquaintance variable an explicit flag which holds values received , we eliminate the overhead of system-wide unique value . Second , the suicide primitive -LRB- Section 2.6 -RRB- is used to optimize memory reclamation . Because a join continuation actor is defined by the compiler , the compiler knows that the continuation actor will become garbage after it has been used only once . Thus , the compiler includes suicide in the definition so that the resources allocated to a join continuation actor can be reused as soon as it becomes garbage . Figure 6 shows the message sending pattern when the transformed program is executed . -LRB- defActor Customer -LRB- a b c -RRB- -LRB- method -LRB- m1 x y -RRB- : -LRB- update a -LRB- bsend m2 -LRB- new Server -RRB- x y -RRB- : -LRB- a -RRB- Before Transformation -LRB- defActor Customer -LRB- a b c flag -RRB- -LRB- all-except m1-continuation flag -RRB- -LRB- method -LRB- m1 x y -RRB- : -LRB- send m2 -LRB- new Server -RRB- x y m1-continuation self -RRB- -LRB- update flag TRUE -RRB- : -RRB- -LRB- method -LRB- m1-continuation x -RRB- -LRB- update a x -RRB- -LRB- update flag FALSE -RRB- -RRB- : -LRB- b -RRB- After Transformation Figure 7 : Transformation with method splitting 3.1.2 Method Splitting When a bsend expression is used with the specification of replacement behavior , we are forced to sacrifice some concurrency in order to maintain the consistency of the actor 's state -LRB- Figure 7 . a -RRB- . If we allow the sender to proceed before it gets the reply back , the sender may see the old value of the acquaintance rather than a new value when it accepts the next message . In this situation , we can not delegate the work dependent on the bsend expression to a continuation . Rather , we split the method executing the bsend expression and add a synchronization constraint to the resulting continuation method -LRB- Figure 7 -RRB- . All methods except the desired continuation method are disabled until the reply has been received , guaranteeing a safe update . 3.2 Optimization on the Replacement Behavior 3.2.1 Transformation for Code Motion of Replacement Behavior The semantics of the Actor model dictates that each communication to an actor is processed on its own version of the actor 's state , allowing pipelining in the execution of the method containing become / update -LSB- 1 -RSB- . This internal concurrency implies that each expression in a method can be executed concurrently and the effect of replacement behavior is visible only to subsequent communications . However , it can be very expensive to utilize all available internal concurrency on conventional multiprocessor architectures . We sacrifice the concurrent execution of each expression of a method while retaining the single assignment semantic of the replacement behavior . However , simple compilation of Hal program into sequential code preserving its textual order is not sufficient to make the effect of replacement behavior invisible to the current computation . In other words , the send expression in the following method definition may use the new value of balance where it is supposed to use the old value . -LRB- method -LRB- deposit amount -RRB- -LRB- update balance -LRB- + balance amount -RRB- -RRB- -LRB- send deposit LogActor balance amount -RRB- -RRB- A straight-forward solution is to have a copy of an actor 's acquaintance list , and perform an update on the copy rather than on the original acquaintance list . At the end of the computation , we can simply replace the acquaintance list with the copy . This solution is simple but has a very high overhead since it requires the entire acquaintance list to be copied whenever we execute the method containing become / update primitives . Our solution is to be as lazy as possible . The very internal concurrency that gives us the problem also allows us to solve it efficiently . We move become / update expressions to the end of the computation so that we can perform update in place . The visibility of the effect of become / update primitives only to the subsequent messages guarantees the operational equivalence between the program before the transformation and the program after the transformation . The use of bsend 's need not affect the equivalence since they have already been detached from the corresponding update 's . -LRB- if -LRB- _ A _ -RRB- -LRB- block : -LRB- update a x -RRB- : -RRB- -LRB- block : -LRB- update a y -RRB- : -RRB- -RRB- -LRB- if -LRB- _ B _ -RRB- -LRB- block : -LRB- update c x -RRB- : -RRB- -LRB- block : -LRB- update c y -RRB- : -RRB- -RRB- -RRB- Figure 8 : Before the transformation to optimize replacement behavior Simply moving update 's to the end of the method is not enough when a program has more than one if expression -LRB- Figure 8 -RRB- . We split each if into two if s , one with no update and the other with update 's only . All if expressions without update 's are placed before all if expressions with update 's only . Splitting if expression makes two copies of the same if condition expression . Unnecessary evaluation of the same conditions can be saved by introducing a let binding -LRB- Figure 9 -RRB- . Nested if expressions are not difficult to transform . let bindings introduced during splitting inner if expressions are promoted to the outer block so that the outer if expression is split as before . -LRB- let * -LSB- -LSB- ra -LRB- _ A _ -RRB- -RSB- -LSB- rb -LRB- _ B _ -RRB- -RSB- -RSB- -LRB- if ra -LRB- block ... -RRB- -LRB- block ... -RRB- -RRB- -LRB- if rb -LRB- block ... -RRB- -LRB- block ... -RRB- -RRB- -LRB- if ra -LRB- block -LRB- update a x -RRB- -RRB- -LRB- block -LRB- update b y -RRB- -RRB- -RRB- -LRB- if rb -LRB- block -LRB- update c x -RRB- -RRB- -LRB- block -LRB- update c y -RRB- -RRB- -RRB- -RRB- -RRB- Figure 9 : After the transformation to optimize replacement behavior 3.2.2 Performance Comparison Table 1 shows the execution time of different number of update 's when we compiled an actor program with 6 acquaintance variables using the earlier version -LSB- 16 -RSB- and the current version of the Hal compiler . The current version uses the optimization which is mentioned in Section 3.2.1 . The reason why the earlier version of Hal takes much more time to perform update 's is that update 's are implemented in the straight-forward way by copying the acquaintance list of the actor . number of updates 1 2 3 4 5 Execution time unoptimized update 285 304 323 342 361 -LRB- unit : cycle -RRB- in place update 17 26 35 44 53 method size unoptimized update 32 33 33 33 33 -LRB- unit : byte -RRB- in place update 17 21 24 26 27 Table 1 : Execution time for updates Table 1 also shows the code size per method in the executable object file . In all cases , optimized update yields less code size . Currently , Hal programs run on the top of the CHARM programming system which is a C based system -LSB- 20 -RSB- . CHARM has been implemented on both shared and distributed memory machines . The total execution time for this simple example was about 0.0527 sec . Over 90 % of the time was spent to execute CHARM kernel code , showing that the start-up overhead of CHARM is very high . In order to further improve performance , we are implementing our compiler on a lower-level run-time system , namely , CHOICES -LSB- 10 -RSB- , an object-oriented distributed operating system , which is known to be more efficient . 4 Related work In this section , we briefly compare our work with several previous efforts to build actor-based parallel languages and their compilers . Note that the first three languages , Act , Cantor and Acore , do not support inheritance and do not provide explicit constructs for specifying synchronization constraints . Act : It compiles the Scripter language into code which can be executed on a simulator for the Actor model , called Apiary , written on Symbolics 3600 Lisp machines . The Act compiler changes most system generated message sending to lisp function calls -LSB- 13 -RSB- . Cantor : Programs written for the Cantor system -LSB- 8 -RSB- can run on either sequential machines or Intel iPSC series machines . All communication is done through asynchronous message passing . Acore : C. Hewitt 's group at M.I.T. implemented the Acore compiler on the Apiary operating system -LSB- 24 -RSB- . It allows for synchronous message passing as well as asynchronous message passing . Rosette : Developed at MCC in collaboration with one of the authors , Rosette -LSB- 30 -RSB- runs on a uni-processor virtual machine . It supports synchronous and asynchronous message passing . Synchronization constraints are specified through enabled sets -LSB- 31 -RSB- which specify the methods that may be invoked by the next message . Enabled sets are mixed in with the code so that Rosette can not support incremental specialization of synchronization constraints . ABCL/R : ABCL -LRB- Actor Based Concurrent Language -RRB- provides for asynchronous , synchronous and future based message passing . ABCL also allows the specification of synchronization constraints . One difference of Hal and ABCL is that ABCL does not support inheritance -LSB- 35 -RSB- . 5 Current Status and Future Research Direction Some practical examples show the performance advantage of using fine-grained inherent concurrency in the Actor model for distributed execution on multicomputers -LSB- 3 -RSB- . However , to design an actorbased language which is easy to use and machine independent , we need to add several linguistic extensions to the basic Actor model . For example , the ability to easily describe synchronization constraints in a high-level , abstract and reusable way is indispensable in a high-level concurrent language : such constructs guarantee the consistent and reliable execution of parallel algorithms . Hal supports the specialization and factorization of both code and synchronization constraints using inheritance . Other features such as sequenced send , RPC style send , and update are added to make the language a general and easily programmable one . The Hal compiler generates a program written in CHARM -LSB- 20 -RSB- as its output . Optimization on the update primitive is implemented in Hal . We are implementing the transformation to extract a join continuation actor . Optimization on synchronization constraints is going to be added in near future . Active research is being done to incorporate distributed data structures in our compiler . A fair amount of effort has been made to preserve the concurrency which is naturally expressed in Hal . Currently , the run-time system for Hal does not support garbage collection . Distributed garbage collector -LSB- 19 , 32 -RSB- should be incorporated in near future . Finally , the compiler should be able to provide the run-time system with information on load balancing and locality control using modular specifications given by the user -LSB- 3 -RSB- . Acknowledgments We would like to thank other members of Open Systems Laboratory at the University of Illinois at Urbana-Illinois , in particular , Svend Frolund and Daniel Sturman for their constructive suggestions for designing Hal , and Raju Panwar and Chirstian Callsen for careful reading the draft of this paper . We also appreciate Chris Houck , a former member of OSL , for his work on designing and implementing the earlier version of Hal . References -LSB- 1 -RSB- G. Agha . Actors : A Model of Concurrent Computation in Distributed Systems . MIT Press , 1986 . -LSB- 2 -RSB- G. Agha , S. Frolund , R. Panwar , and D. Sturman . A Linguistic Framework for Dynamic Composition of Fault-Tolerance Protocols . Technical Report UIUCDCS-R-92-1730 , University of Illinois at Urbana-Champaign , April 1992 . -LSB- 3 -RSB- G. Agha , C. Houck , and R. Panwar . Distributed Execution of Actor Systems . In Proceedings of Fourth Workshop on Languages and Compilers for Parallel Computing , Santa Clara , 1991 . -LSB- 4 -RSB- A. Aho , R. Sethi , and J. Ullman . Compilers : Principles , Techniques and Tools . Addison Wesly , 1986 . -LSB- 5 -RSB- R. Allen and K. Kennedy . Automatic Translation of Fortran Program to Vector Form . ACM Transactions on Programming Languages and Systems , 9 , 1987 . -LSB- 6 -RSB- P. America and F. van der Linden . A Parallel Object-Oriented Language with Inheritance and Subtyping . In OOPSLA ' 90 , pages 161 -LCB- 168 , October 1990 . -LSB- 7 -RSB- Arvind and D. Culler . Annual Reviews in Computer Science , chapter Dataflow Architecture , pages 225 -LCB- 253 . Annual Reviews Inc. , 1986 . -LSB- 8 -RSB- W. Athas and C. Seitz . Cantor User Report Version 2.0 . Technical Report 5232 : TR :86 , California Institute of Technology , Pasadena , CA , January 1987 . -LSB- 9 -RSB- S. Brookes , C. Hoare , and A. Roscoe . A Theory of Communicating Sequential Processes . Communications of the ACM , 31:560 -LCB- 599 , July 1984 . -LSB- 10 -RSB- Roy H. Campbell , Vincent Russo , and Gary Johnston . Choices : The Design of a Multiprocessor Operating System . In Proceedings of the USENIX C++ Workshop , pages 109 -LCB- 123 , Santa Fe , New Mexico , November 1987 . IEEE . -LSB- 11 -RSB- N. Carriero and D. Gelernter . Linda in Context . Communication of the ACM , 32 -LRB- 4 -RRB- :444 -LCB- 458 , April 1989 . -LSB- 12 -RSB- A. Chien . Concurrent Aggregates : An Object-Oriented Language for Fine-Grained MessagePassing Machines . PhD thesis , MIT , July 1990 . -LSB- 13 -RSB- P. de Jong . Compilation into Actors . SIGPLAN Notices , 21 -LRB- 10 -RRB- :68 -LCB- 77 , October 1986 . -LSB- 14 -RSB- N. Francez . Fairness . Texts and Monographs in Computer Science . Springer-Verlag , 1986 . -LSB- 15 -RSB- S. Frolund . Inheritance of Synchronization Constraints in Concurrent Object-Oriented Programming Languages . In Proceedings of European Conference on Object-Oriented Programming , 1992 . -LRB- to appear -RRB- . -LSB- 16 -RSB- C. Houck . Run-Time System Support for Distributed Actor Programs . Master 's thesis , University of Illinois at Urbana-Champaign , January 1992 . -LSB- 17 -RSB- C. Houck and G. Agha . HAL : A High-level Actor Language and Its Distributed Implementation . In 21st International Conference on Parallel Processing -LRB- ICPP ' 92 -RRB- , August 1992 . -LRB- to appear -RRB- . -LSB- 18 -RSB- P. Hudak . Conception , Evolution and Application of Functional Programming Languages . ACM Computing Surveys , 21 -LRB- 3 -RRB- :359 -LCB- 411 , September 1989 . -LSB- 19 -RSB- D. Kafura , D. Washabaugh , and J. Nelson . Garbage Collection of Actors . In OOPSLA ' 90 , pages 126 -LCB- 134 , October 1990 . -LSB- 20 -RSB- L. Kale . The CHARM -LRB- 3.0 -RRB- Programming Language Manual . University of Illinois , February 1992 . -LSB- 21 -RSB- D. A. Kranz . ORBIT : An Optimizing Compiler for Scheme . PhD thesis , Yale University , February 1988 . YALEU/DCS/RR -632 . -LSB- 22 -RSB- W. LaLonde and J. Pugh . Inside Smalltalk , volume 1 . Prentice Hall , 1990 . -LSB- 23 -RSB- P. Maes . computational reflection . Technical Report 87-2 , Vrije University . Artificial Intelligence Laboratory , 1987 . -LSB- 24 -RSB- C. Manning . ACORE : The Design of a Core Actor Language and its Compiler . Master 's thesis , MIT , Artificial Intelligence Laboratory , August 1987 . -LSB- 25 -RSB- D. May , R. Shepherd , and C. Keane . Communicating Process Architecture : Transputer and Occam . In P. Treleaven and M. Vanneschi , editors , Future Parallel Architecture , pages 35 -LCB- 81 . Springer-Verlag , 1986 . LNCS 272 . -LSB- 26 -RSB- D. Padua and M. Wolfe . Advance compiler optimizations for supercomputers . Communication of the ACM , 29 -LRB- 12 -RRB- :1184 -LCB- 1201 , December 1986 . -LSB- 27 -RSB- C.D. Polychronopoulos , M.B. Girkar , M.R. Haghighat , C.L. Lee , B.P. Leung , and D.A. Schouten . The Structure of Parafrase-2 : an Advanced Parallelizing Compiler for C and Fortran . In D. Gelernter , A. Nicolau , and D. Padua , editors , Languages and Compilers for Parallel Computing , pages 423 -LCB- 453 . The MIT press , 1990 . -LSB- 28 -RSB- B. C. Smith . Reflection and semantics in a procedural language . Technical Report 272 , Massachusetts Institute of Technology . Laboratory of Computer Science , 1982 . -LSB- 29 -RSB- G.L. Jr. . Steele . RABBIT : a compiler for SCHEME . AI Memo 474 , MIT , May 1978 . -LSB- 30 -RSB- C. Tomlinson , W. Kim , M. Schevel , V. Singh , B. Will , and G. Agha . Rosette : An Object Oriented Concurrent System Architecture . SIGPLAN Notices , 24 -LRB- 4 -RRB- :91 -LCB- 93 , 1989 . -LSB- 31 -RSB- C. Tomlinson and V. Singh . Inheritance and Synchronization with Enabled-Sets . In OOPSLA , 1989 . -LSB- 32 -RSB- N. Venkatasubramian . Hierarchical Memory Management in Scalable Parallel Systems . Master 's thesis , University of Illinois at Urbana-Champaign , 1991 . -LSB- 33 -RSB- T. Watanabe and A. Yonezawa . ABCL An Object-Oriented Concurrent System , chapter Reflection in an Object-Oriented Concurrent Language , pages 45 -LCB- 70 . MIT Press , Cambridge , Mass , 1990 . -LSB- 34 -RSB- P. Wegner . Dimensions of Object-Based Language Design . Technical Report CS-87-14 , Brown University , July 1987 . -LSB- 35 -RSB- A. Yonezawa , editor . ABCL An Object-Oriented Concurrent System . MIT Press , Cambridge , Mass. , 1990 .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O B O O O O O O O B O O O O O O O O O O B O O O O O B O O O O O O O B I O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

actor
concurrency
inheritance
optimization
synchronization constraint