Implementing a Programming Model Integrating Functional and Object-Oriented Models on Multithreaded Architecture: DAVRID

By

Juno Chang, Sangyong Han

Dept. of Computer Science, Seoul National Univ., Seoul, 151-742, Korea

Soohong Kim
Dept. of Computer Science, Sangmyong Univ., Chonan, Chungcheong-Do, 330-180, Korea

Heunghwan Kim
Dept. of Computer Science, Seowon Univ., Cheongju, Chungcheong-Do, 360-742, Korea

ABSTRACT
Multithreading has been studied to solve two fundamental problems in Massively Parallel Processing: communication latency and synchronization. DAVRID(DAtaflow Von Neumann RISC HybrID) is a multithreaded architecture which is based on a hybrid of von Neumann and dataflow computational model. It has been operational since 1993. In programming application programs, there are largely two kinds of techniques: procedural and object-oriented. We presently use a functional language Id , which is a subset of a parallel programming language Id designed by MIT. To use the good features of objectoriented technique and widen the applications of multithreaded computation, we have developed and implemented a programming model integrating functional and object-oriented on DAVRID. This programming model exploits the comparative advantages of both functional and object-oriented model, and exploit another kind of parallelism by multithreading: inter- and intra-object parallelism.
-

1. INTRODUCTION
Multithreaded architecture is proposed to address the asynchrony problem by context switching among threads. This has been studied from two different approaches. The one is based on conventional von Neumann computation model and the other is based on dataflow model. Conventional von Neumann model, however, may suffer from inefficient synchronization mechanism and communication latencies. In contrast, dataflow model causes problems of excessive synchronization costs and inefficient execution of sequential programs while it offers the ability to exploit massively parallelism inherent in programs[1]. Therefore, hybrid multithreaded architectures are proposed to take advantages of two computational models. They not only preserves good single thread performance but also

-1-

tolerates latency and synchronization costs. *T[2] is a typical approach trying to achieve good single thread performance with a conventional microprocessor. However, even if it uses a separate coprocessor for message handling, remote memory requests may cause conflicts since global and local data are stored in the unified node memory. In TAM[3] and P-RISC[4], the division of work between thread computation and message handling is not considered. Thus, there may be problems in handling the remote memory requests. Especially, in TAM, there is a considerable scheduling overhead[4]. DAVRID(DAtaflow Von Neumann RISC hybriD)[5,6] is a multithreaded architecture, which is based on a hybrid of von Neumann and dataflow computational model. It has been operational since 1993. DAVRID has a special synchronization unit and a global memory placed in the outside of the node. On DAVRID, we use Id language, a major subset of Id[7,8] which is a parallel programming language designed by MIT. Id is a pure functional language with non-strict semantics. We extends Id with explicit loop unfolding degree, which is given to the compiler as information for loop unfolding[6]. In this paper, we propose a programming model integrating a functional and an objectoriented models. This proposed programming model is guided by three observations. The first is that functional languages have been attractive for their expressive power and clean semantics. Since a functional language has no notion of state, it makes it easy to write parallel programs without races. The second is the limitation of functional programming languages. In spite of the above merits, there is a critical problem that functions do not have a history[9]. Programs written in functional language is suitable for applications such as scientific computation where side effects are undesirable and avoidable, not for applications such as database applications. So, we need to widen the application of multithreaded computations. The third is that object-oriented programming languages promote the programming
-

productivity and have great potential for exploiting concurrency and parallelism. The features of object-oriented programming, such as information hiding, data abstraction, polymorphism, and inheritance, are being quite widely used in many areas[10]. These three observations lead to our underlying philosophy. 1. exploiting the comparative advantages of both functional and object-oriented programming, and 2. exploiting another kind of parallelism by multithreading: inter- and intra-object parallelism. Therefore, in our programming model, the programmer can write functional programs with object-oriented features, which is added orthogonally, regarding an object as an unit of concurrency. Section 2 describes the programming model of DAVRID and its node architecture.

-2-

Section 3 describes parallelism in object-oriented language, especially inter- and intra-object parallelism in our programming model. Section 4 presents our OOId(Object-Oriented Id) system and extended PML(Parallel Machine Language). Section 5 describes how to map our programming model onto DAVRID. Section 6 remarks our related works. Finally, we give a conclusion in Section 7.

2. DAVRID
The programming model of DAVRID is based on the multithreaded computational model, which is a hybrid of von Neumann and dataflow model. In the multithreaded model, a program is partitioned into threads before its execution. A thread is a sequence of instructions in which no latency-sensitive operations are intervened. These facts guarantee that communication latency is effectively hidden in parallel instruction execution. On the other hand, synchronization between threads is carried out by dataflow computing rule, which provides a natural way of synchronization. In DAVRID, a thread can be scheduled to a processor when the thread is fully synchronized by the response of long latency operations requested by other threads, or signals from other threads. Once a thread is scheduled to a processor, the thread is nonpreemtively executed, accessing memory and registers. During execution, the thread generates messages to remote memory and other threads, if necessary. The processor switches its control to another thread as soon as the thread dies. A thread is identified by a continuation <fp, tp>; fp, frame pointer, is the base address of a frame containing data for a function, and tp, thread pointer, is the starting address of the thread in program memory, as shown in Figure 1(a). Another status indicator of a thread is the synchronization counter that shows if all events, which are needed for the execution of the thread, have been occurred. The event is an arrival of a value or a signal. In the frame, a synchronization counter and related thread code pointer(tp) are located at a word addressed by offset, and a frame slot is allocated at a location addressed by displacement. The synchronization counter is initialized to the number of events needed for the activation of the thread. When an event occurs, the synchronization counter is decreased by 1, and a value, if exists, is stored at the frame slot. If the synchronization counter is 0, the related thread is able to be activated. This is the firing rule of dataflow computational model which is characterized by its natural synchronization. Figure 1(b) shows the representation of a thread.

-3-

(a) continuation

(b) the representation of a thread

Figure 1. continuation and thread representation in DAVRID DAVRID consists of a collection of clusters, which communicate using a pipelined, message based interconnectin network, as shown in Figure 2. Each cluster has nodes up to four and node-to-node communication is done via NIMU(Node Interface and Management Unit). Each node has its own local memory and may work independently. Global memory, called SM(Structured Memory), are placed in NIMU.

Figure 2. DAVRID architecture DAVRID has its own instruction set, called PML(Parallel Machine Language). The PML includes instructions for synchronization of threads, global memory access, dynamic memory management, and conventional load/store, arithmetic/logic, and branch. A node consists of TPU(Thread Processing Unit), SU(Synchronization Unit), FM(Frame Memory), and message queues, as shown in Figure 3. The TPU is a core unit executing threads. It consists of a conventional RISC processor and TM(Thread Memory) which contains program codes. The SU is a unit for synchronization. These two units communicate using ATQ(Active Thread Queue) and STQ(Setup Token Queue), and share the FM. TPU gets a continuations from the ATQ and executes the corresponding thread repeatedly. For messages destined for its own node, values of the message is directly stored into FM and other information is sent to STQ, which eliminates unnecessary node-to-node traffic.

-4-

Figure 3. Organization of the DAVRID node

3. PARALLELISM IN OBJECT-ORIENTED LANGUAGES

The object-oriented paradigm is ideal for parallel and distributed systems because users of an object interact with the object via the objects interface. The objects data hiding, or encapsulations properties prevent direct access of private object data. This simplifies concurrency control on object data structures, since objects can be treated as monitors[11]. Our programming model extends these notions to include inter- and intra-object parallelism by object distribution among nodes and multithreading in a node.

3.1 INTER-OBJECT PARALLELISM

Object-oriented programming provides abstractions about the object data structures and member functions. The runtime system uses these abstractions to appropriately schedule functions that reference the same objects on the same processor. This function scheduling and object distribution make inter-object parallelism possible and also exploit data locality in each node. This approach provides a clear separation of functionality. The programmer can focus on exploiting parallelism and supplying hints about the object reference patterns, leaving the task-creation details and management to the implementation. To illustrate the inter-object parallelism, suppose A, B, C, D, E and F are matrix objects and multiply is a member function which multiplies own matrix by the matrix passed as an argument. Consider the sequence of statements C = A.multiply(B); F = C.multiply(D.multiply(E)); In a sequential computation, the matrices A and B are multiplied first, with the result stored in C, followed by the multiplication of D and E. The final step is to multiply C by the

-5-

result of D.multiply(E). If we assume that each multiplication takes one time unit, three time units are required to complete the computation. In our model, the compiler and runtime system detect that the first two multiplications, A.multiply(B) and D.multiply(E), have not data dependency each other and can be safely executed in parallel. As the execution graph in the Figure 4, it takes only two time units. We can get the speedup about 1.5 for this example.

Figure 4. Inter-object parallelism

3.2 INTRA-OBJECT PARALLELISM

Since an object is an unit of concurrency, an object does not span multiple nodes. An object owns many member functions. Parallelism among functions and among threads within a function can be exploited by multithreading. We call this intra-object parallelism. Figure 5(a) shows that the multiplication of the above example are partitioned into many threads denoting several contexts. When each multiply instruction requires two elements allocated in remote memory, remote loads block the execution during communication. At that time, we switch the context to tolerate this communication latency. By this type of multithreading, we can overlap the computation with communication. Those improve the performance, Figure 5(b) describes the details of one multiplication.

(a) the multiplications are partitioned into many threads

-6-

(b) The details of one multiplication Figure 5. Intra-object Parallelism

4. OOId (OBJECT-ORIENTED Id) SYSTEM

Our programming model is proposed to integrate functional and object-oriented programming. It keeps many attractions of the functional programming and exploit another kind of parallelism by multithreading: inter- and intra-object parallelism. We will describe OOId system which is based on functional language and extended with object-oriented features. A program is compiled through just like the conventional DAVRID compilation phases. In DAVRID compiler[6], the compilation process is largely divided into two steps, a front and a back end. In the front end, Id- program is converted into intermediate code called PARFIC. A PARFIC program has only simple expressions, and an operation code of each statement in the program can be directly mapped into a node of abstract dataflow graphs, called program graphs, which contain no detailed knowledge of the target architecture. The back end is to translate the program graphs into machine code, which can be efficiently executed on DAVRID. Finally, thread codes are generated for each partition of machine graph[12], which are represented in the DAVRID PML(Parallel Machine Language). In this section, we describe the syntax and the translation of OOId. Then, we present an object frame structure and extend the DAVRID PML to realize the OOId system.

4.1 SYNTAX
OOId is an extension of Id- with object-oriented features, which are class definitions, member function invocations, and so on. In terms of syntax, what makes OOId be different from Id- is just a few. Those are an expression for class definition, member function invocation, and a pattern for class-type identifier. The expression for class definition is as follows.

-7-

exp ::= '{' CLASS block '}' Using above expression, we can define a class as similar as function definition as follows. ClassName = CLASS { internal-variables; member-functions; }; The fact that a class definition has a similar form with a function definition means an object creation is represented by the same way of applying a function. The following two examples in Figure 6 show how to define a class and member functions of that class, and the way to create an object and apply member functions. When pointers are used as arguments of a member function, the designated objects frame pointer or the address of structured variable is sent to the callee. As we show in Figure 6(b), we have an implicitly declared selfreferential pointer, THIS.
{ account=CLASS { balance=0; withdrawal={ Fun w_account = { in (if (balance > w_account) then { balance=balance-w_account; in TRUE} else { in False}}; deposit={ Fun amount = { in (if (amount > 0) then { balance=balance+amount; in TRUE} else { in FALSE}}; }; } _=(account student1); _=(student1.deposit 1000); _=(student1.withdrawal 500);} (a) simple bank application { Array=CLASS int s = Iarray(1, n); intialize={ Fun = { _= for i <- 1 to n step 1 do s[i] = i; } In s } multiply={ Fun Array_X = {_=(Array temp); _={ for I <- 1 to n step 1 do temp.s[i] = THIS.s[i]*Array_X.s[i];} In temp } }; _=(matrix a b); In (a.multiply b);} (b) multiplication of two array objects

Figure 6. Examples for OOId program

4.2 TRANSLATION OF OOId

The conventional DAVRID compiler, in first phases of the front end, eliminates explicit environments containing the value of free variables of a function through lambda-lifting[13] and resolves block scoping of identifiers by renaming technique. It carries out type checking and other compiling activities. In addition, we construct an information table for class and member functions during translation of OOId program into PARFIC program. We make every member function have a unique name, since it is possible that more than one functions have the same name in different classes. We also need to extend PARFIC to support an object creation and a member function call. An OOId expression for object declaration is translated into Ob_Creator expression. If C is a class name and O1, O2 are objects of class C, declaration of O1 and O2 is translated as follows. (C O1 O2) => Ob_Creator(C, O1, O2)

The member function application is translated as follows, where O is an object name and f is a name of O's member function.

-8-

((O.f x y) (O.f x)

=> MFAp(O, g, x, y) => MAp1(O, g, x)

((O.f x) y) => { h=MAp1(O, g, x); t=MApN(O, h, y); In t } Since DAVRID compiler supports the function currying through closure [14], we translate a member function application into one of three expressions, MAp1, MApN or MAFp, depending on the number of the function arguments, and the type of f which is a function name or a closure name. MAp1 is used for applying a function to the first argument, and MApN is used for applying a closure to the other argument. These two operators should have just three operands including an object name, while MFAp can have more than three operands. When all arguments of the function are provided at once, MFAp is used. As the above expressions show, every member function is renamed and h is a closure name.

4.3 OBJECT FRAME

An object is the basic unit of concurrency. Each has its own autonomous thread of control and local memory. Each object is represented by an object frame. The object frame holds an object name and basic state information, like parent function frame pointer, current object frame pointer, and several continuations for realizing the frame initialization protocol. In addition, it holds synchronization counter(SC) and thread pointer(TP). It also holds internal variables area for both scalar and structured variables. In case of structured variable, it holds just pointers to structured variables which is allocated in remote shared memory. Further, it holds child object pointer for realizing the inheritance. frame size object name parent frame pointer current object pointer parent object pointer child object pointers return initialization signal continuation SC TP

scalar variables area structured variable pointers Figure 7. object frame structure

-9-

4.4 EXTENDED PML(Parallel Machine Language)

The conventional DAVRID PML includes the instructions for the followings: 1.thread synchronization and initiation, 2.dynamic allocation and deallocation of memory, and 3.communication with the host. We need to extend the DAVRID PML to include the instructions for allocating an object frame and sending messages between objects. A GETob_FRAME instruction is used for object frame allocation;

GETob_FRAME object-name, size, offset, displacement, init-cont.

When it is executed, < GETob_FRAME ... > message is generated and sent to NIMU, and then forwarded to some node. SU of the node which receives this message allocate frame memory with size, and get object initialization thread pointer(OITP) from an object table. If it gets an object frame pointer, it bypasses <START fp, offset, displacement, op> message to the node which requests the object frame allocation, and then put <op, oitp> continuation in ATQ to initialize the allocated object frame. When a member function of an object needs other object as an argument, it sends a message to other object to load a variable which is belong to that object. An instruction OLOAD is for this end.

OLOAD object-name, fp, offset, displacement1, displacement2

When it is executed, <OLOAD, object-name, fp, offset, displacement1, displacement2> message is generated and sent to the node which has such a variable. The node who receive this message, sends <START fp, offset, displacement1, value> message back to reply the OLOAD.

5. HOW TO MAP OOId ONTO DAVRID

In this section, we describe the details of object creation and member function invocation with an object and a function frame. Finally, for a simple example, we demonstrate the mapping process from source program to thread code.

5.1 OBJECT CREATION

Creating an object means that an object frame is allocated in a node. An object frame is allocated in a (remote) node by sending an object-frame-allocation message,

GETob_FRAME, to the unit, NIMU, which takes charge of the load balancing. The NIMU marks in object table which node that message will be sent to. The object table holds object

- 10 -

ID, node number, and object frame initialization thread pointer. Then, NIMU forwards the object-frame-creation message to the node which has relatively light load. If a node receives the message, the nodes object manager, SU, allocates an object frame in frame memory, sends the object frame pointer to the reply address, and executes the object frame initialization thread. The Figure 8 shows these object creation sequence.

Figure 8. object creation sequence

The initialization thread fills out an allocated object frame for return continuation, scalar variables as an internal variable, synchronization counter, and thread pointers. If the initialization thread need to allocate structured variables as internal variable, it sends a message for structured-variable-allocation to the unit, NIMU, which contains a structured memory. When all structured variables are allocated in structured memory, the allocation of an object frame is over.

5.2 MEMBER FUNCTION INVOCATION

Since OOId system provides an object-oriented programming model based on functional programming and frame-based synchronization mechanism, there must be a main function frame that holds the information for object creation, the number of created objects and their frame pointers. The following shows the main function frame structure. current function frame pointer SC TP

- 11 -

object frame pointer1 object frame pointern Figure 9. main function frame structure A function frame for DAVRID should be expanded to have the pointer to an object who owns that function. Moreover, since the member function can also create objects, there is the area for object creation in function frame. The member function invocation has the same mechanism with that of normal function invocation of DAVRID[6]. Size current function frame pointer owner object frame pointer function initialization signal continuation function name return signal continuation the number of return values SC object frame pointer1 object frame pointern area for arguments Figure 10. member function frame structure TP

5.3 AN EXAMPLE: MULTIPLICATION OF ARRAY OBJECTS

In this section, we demonstrate the mapping process for an OOId example in Figure 6(b). We also show its program graph and the part of thread base code for multiplication of two array objects. In that program, there is a class Array that contain a structured variable, s, and two member functions. The one, initialize, is for initializing structured variable. The other, multiply, is for multiplying two structured variables. Figure 11 shows the program graph for Main Block, Class definition, and two function definitions.

- 12 -

(a)

Main Block

(b) Class Definition for Array

(c) Function Definition for initialize

(d) Fucntion Definition for multiply Figure 11. Program Graph for multiplication of two array objects

- 13 -

In this program, two object, a, b will be created at first. We assume that the main function frame contains pointers for two object frame, synchronization counter and next thread pointer as the following.

offset 8 12 16 SC

content TP

pointer to object a pointer to object b

#***************************************** # Function(Program) #***************************************** # Thread(1) (sc:0) (offset:8) at 0 #=========================== BEGIN: GETob_FRAME 1,1,8,12,8 GETob_FRAME 2,1,8,16,8 NEXT ... Figure 12. Main Function Frame and thread base code The first thread for the main block create two objects in two node. As we described above, two object-frame-creation messages, GETob_FRAMEs will be generated. In each node which receives the GETob_FRAME message, the object manager, SU, allocates an object frame with size and makes an object initialization thread be executed. Then, a structured-variable-allocation message, HALLOC[6], is generated and sent to NIMU. The member function, initialize, assigns fixed values to the allocated structured variable through loop function in parallel. The parallel loop function unfolds the loop in that node to the degree of unfolding. The GETpl1_FRAME[6] instruction is used for that purpose. In the case of the object a, our compiler detects its member function, multiply, and generates the parallel loop functions which executes with an object b as an argument. Figure 13,14 show the object frames of object a, b respectively.

offset 8 12 16 20 24

contents Size ObjectName : 1(a) pointer to parent function frame pointer to current object frame return init. signal continuation

- 14 -

28 32 36 40 44 48 52 56

SC(1) TP:structured variable allocation continuation SC(2) TP:init_CSC for loop function 1(initialize) SC(3) TP:cleanup_CJC for loop function 1(initialize) SC(2) TP:init_CSC for loop function 2(multiply) SC(3) TP:init_CJC for loop function 2(multiply) pointer to loop function 1 (initialize) pointer to loop function 2 (multiply) address of structured variable(A_0) #***************************************** # Object(a) #***************************************** # Thread(1) (sc:0) (offset:8) at 0 #=========================== BEGIN: HALLOC_ 28,56,1,1,10 GETpl1_FRAME 1,2,1,32,48,32,36 GETpl1_FRAME 2,2,1,40,52,40,44 NEXT ...

Figure 13. object frame and thread base code for object a

offset 8 12 16 20 24 28 32 36 40 44 SC(1) SC(2) SC(3)

contents Size ObjectName : 2(b) pointer to parent function frame pointer to current object frame return init. signal continuation TP:structured variable allocation continuation TP:init_CSC for loop function 1(initialize) TP:cleanup_CJC for loop function 1(initialize) pointer to loop function 1 (initialize) address of structured variable(B_0) #***************************************** # Object(b) #*****************************************

- 15 -

# Thread(1) (sc:0) (offset:8) at 0 #=========================== BEGIN: HALLOC_ 28,44,1,1,10 GETpl1_FRAME 1,2,1,32,40,32,36 NEXT ... Figure 14. object frame and thread base code for object b

6. RELATED WORK
There are many works focusing on how to design and implement object-oriented models and languages suited for multiprocessing systems. In [15], Yonezawa and his research group presented ABCM(An object-Based Concurrent computation Model)[16] and implemented ABCM on EM-4 to eliminate the performance bottleneck which is caused by the high cost of inter- and intra-node message passing among objects. Their ABCL model performs computation by transmitting message among a collection of software modules that become active when they accept messages. More than one of these concurrent objects can be active at the same time, and more than one transmission can take place in parallel. From this point of view, our programming model is similar to ABCM. However, there is a great differences between two models. The ABCM model uses ABCL as programming language, which is Actor-based language. On the contrary, our programming model use object-oriented language based on functional language. From [17], there are some differences between Actors and Object-Oriented languages. In Mentat[11], developed by Grimshaw and his research group, the user can specify the granularity and partitioning decisions using extended C++ while the compiler and run-time system manage communication, synchronization, and scheduling. There are many other systems and projects[18,19,20] that are similar in some respects to Mentat, since an easy way to provide concurrent object-oriented programming systems might be to augment C++ with communication and synchronization libraries that must be explicitly used by programmers. However, this approach does not offer the computational power and efficiency needed for high-performance computing because the implementations of built-in thread manipulation and internode communication facilities are often not well tuned for fine-grain, highly parallel concurrent objects[15]. What make our work be different from other concurrent and distributed object-oriented systems are the OOId system integrating functional and object-oriented programming model and its emphasis on another kind of parallelism by multithreading: inter- and intra-object parallelism. Those improve the multithreading for the parallel processing domain.

7. CONCLUSION AND FUTURE WORK

- 16 -

Our programming model focused on exploiting the comparative advantages of both functional and object-oriented programming. We inherit features from both, compiler techniques from the functional programming languages, and program productivity from the object-oriented programming. These widen the application of multithreaded architectures. We also get the good features, Inter- and Intra-object parallelism, from integrating the multithreading and object-oriented paradigm. We developed the software architecture to implement our model on multithreaded architecture, DAVRID. On our OOId system, the programmer can write a program expressing implicit parallelism fully, and supplying the hints data locality and load balancing through abstraction. It is also possible that other research[21] for alleviating limitation of functional languages on multithreaded architecture can be experimented through the advantages which our programming model provides. Improving data locality is another our future research topic. The COOL[18] has been implemented on several shared-memory multiprocessors and a variety of application programs have been written in the language. We have experimented to evaluate several approach to exploiting data locality with programs written in OOId on DAVRID. The inheritance mechanism in most sequential object-oriented languages is also important for code reuse in concurrent object-oriented programming. However, inheritance often makes it hard to reuse object-oriented programs with synchronization constraints[22]. The current version of our software architecture does not support an inheritance mechanism, but we reserved slots for pointers to parent or child object in an object frame and we are working on that problem.

REFERENCES/BIBLIOGRAPHY

[1] Arvind and R.A.Iannucci, Two Fundamental Issues in Multiprocessing, MIT CSG Memo 226-5, July, 1986. [2] R.S. Nikhil, G.M. Papadopoulos, and Arvind, *T: A Multithreaded Massively Parallel Architecture, In Proc. 19th Annual Intl Symp. on Computer Architectue, 1992, pp.156167. [3] D.E. Culler, S.C. Goldstein, et al., TAM-A Compiler controlled Threaded Abstract Machine, J. of Parallel and Distributed Computing, Vol. 18, 1993, pp.347-370. [4] R.S. Nikhil, A Multithreaded Implementation of Id using P-RISC Graphs, In Proc. 6th Annual Workshop on Languages and Compilers for Parallel Computing, 1993. [5] S.Y.Han, et al., A Massively Parallel Multithreaded Architecture: DAVRID, In Proceedings of IEEE Intl Conf. on Computer Design, Oct. 1994, pp.70-74. [6] S.Y.Han, et al., Compilation of a Functional Language for the Multithreaded Architecture: DAVRID, In Proceedings of Intl Conf. on Parallel Processing. Vol. 2, Aug. 1994,

- 17 -

pp.239-242. [7] R.S. Nikhil, Id - Language Reference Manual(Version 90.1), MIT CSG Memo 284-2, July, 1991. [8] R.S. Nikhil and Arvind, Id: a Language with Implicit Parallelism, A Comparative Study of Parallel Programming Languages: The Salishan Problems, Elsevier Science Publishers B.V., 1992, pp169-215. [9] Gul Agha, Foundational Issues in Concurrent Computing, SIGPLAN NOTICES, Vol. 24, No. 4, April, 1989. [10] Gao Yaoqing, Y.C. Kwong and A. Yonezawa, Issues on implementing ABCL on Massively Parallel Machines, pp.447-452. [11] Andrew S. Grimshaw, Easy to Use Object Oriented Parallel Processing with Mentat,IEEE Computer, Vol. 26, No. 5, May 1993, pp.39-51. [12] S. Ha, S.Y. Han, and H. Kim, Partitioning a Lenient Parallel Language into Sequential Threads, In Proceedings of the 28th Hawaii Intl Conf. on System Science, Vol. 2, 1995, pp.83-92. [13] T. Johnsson, Lambda Lifting: Transforming Program to Recursive Equations, In Springer-Verlag LNCS 201, Sep. 1985. [14] S.Y. Han, M.S. Park, D.J. Hwang, and H.H. Kim, A Study on the Parallel Computer Architecture, ATRC-409-92525, Korean Agency for Defence Development, 1992. [15] Akinori Yonezawa, et. al., Implementing Concurrent Object-Oriented Languages on Multicomputers, IEEE Parallel & Distributed Technology, Vol. 1, No. 2, May 1993, pp.49-61. [16] Akinori Yonezawa, Jean-Pierre Briot and Etsuya Shibayama, Object-Oriented Concurrent Programming in ABCL/1, OOPSLA 86 Proc. 1986, pp.258-268. [17] Franoise Carr and Pscal Clr, Object-Oriented Languages and Actors: which language for a distributed approach?, SIGPLAN NOTICES, Vol. 24, No. 4, April 1989. [18] Chandra, A. Gupta, and J.L. Hennessy, COOL: An Object-Based Language for Parallel Programming, IEEE Computer, Vol. 27, No. 8, Aug., 1994, pp13-26 [19] B.Beck, Shared Memory Parallel Programming in C++, IEEE Software, Vol. 7, No. 4, July 1990, pp.38-48. [20] J.K. Lee and D. Gannon, Object-Oriented Parallel Programming Experiments and Results, Proc. Supercomputing 91, IEEE CS Press, Los Alamitos, Calif., Order No. 2159-02, pp.273-282. [21] E.H. Rho, H.H. Kim, D.J. Hwang, and S.Y. Han, Effects of Data Bundling in Non-Strict Data Structures, Proc. of Parallel Architectures and Compilation Techniques 95, 1995, pp140-148 [22] S.Matsuoka and A. Yonezawa, Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages, Research Directions in Concurrent Oobject-

- 18 -

Oriented Programming, G. Agha, P.Wegner, and A.Yonezawa, eds., MIT Press, Cambridge, Mass., 1993.

- 19 -