An Efficient Compilation Framework for Languages Based on a Concurrent Process Calculus

1. An Efficient Compilation Frameworkfor Languages Based on a Concurrent Process Calculus Yoshihiro Oyama Kenjiro Taura Akinori Yonezawa Yonezawa Laboratory Department of Information Science University of Tokyo

2. many primitives surface language several essential primitives intermediate language implementation becomes easy analysis becomes general machine code Compiling Programming Languages implementation is difficult analysis is not general

3. Intermediate Languages • Sequential languages • Quadruple • Lambda calculus • Continuation Passing Style (CPS) [Appel 92] • Concurrent languages • Pi-calculus [Milner 93] • HACL [Kobayashi et al. 94] process calculus

4. Concurrent Process Calculus • Key component of calculation • Asynchronous process • Communication channel • Advantages • Clear syntax and clear semantics • Many theoretical results for optimization P 3 P P C 3 P P

5. straightforward translation focus of our research traditional techniques Goal • Efficient implementation of a process calculus Schematic code HACL code ML-like code …..

6. Low efficiency with naïve implementation A demand on a sophisticated implementation reducing the overheads Motivation Process calculus has some overheads which are not in sequential languages • Dynamic process scheduling • Channel communication

7. Contribution • A framework for compiling process calculus efficiently • Optimization techniques applicable for software multithreading

8. Overview of This Presentation • Target language HACL • A basic execution • Our enhanced execution • To reduce scheduling overhead • To reduce communication overhead • Experimental results

9. expression e ::= x | c | op(e1, …, en) Target Language HACL process definition x0 (x1,…, xn)= P process expression parallel execution P ::= P1| P2 channel creation $x.P receive from e e(x)=>P send e2 to e1 e1<=e2 process instantiation e0 (e1, …, en) if e then P1else P2 conditional

10. both schedulable continuing execution Basic Execution Model (1/2)- process scheduling - P1| P2……… dynamic process creation schedulable process | P２ P１ P P２ P P scheduling pool

11. Basic Execution Model (2/2)- channel - channel ⇔ pointer to memory space r value queue r(y)=>Q r(x)=>P r<=12 r<=8 12 Q process queue r<=12 { 12 / x } P r(x)=>P r(y)=>Q {8 / y} Q r<=8

12. Inefficiencies of Basic Model • Scheduling overhead • Scheduling pool is manipulated every time a process is created • Communication overhead • Channel communication is always performed through memory

13. Our Enhanced Execution Model • Static process scheduling • reduces the frequency of the runtime scheduling pool manipulation • lines up code fragments for multiple process expressions • Unboxed channel framework • enables us to communicate values without memory • initially creates a channel on register • later allocates a channel on heap as necessary

14. Compilation Overview execution flow scheduling pool = implicit HACL program translation rule a set of schedulable process expressions F { P1, P2, ..., Pn } = a sequential ML-like program which schedules P1, P2, ..., Pn execution flow scheduling pool ML-like program = explicit

15. code fragment for P1 code fragment for P2 F P1 P2 P3 F F P2 P3 P3 Compilation with Static Scheduling (1/2) code fragment for P3 =

16. if (r has a value) then (* get the value from r *) code fragment for P1’ F r(x)=> P1’ P2 else (* allocate a closure for on heap *) F P1’ P2 P1’ F F P2 P2 Compilation with Static Scheduling (2/2) code fragment for P2 = code fragment for P2

17. Compilation Example $r.(r<=5|r(x)=>P) F { ($r.(r<= 5 |r(x)=>P)) } r= new_channel(); if(r has a waiting process)then (* wake up the process and … *) else put_value(r,5); F { (r<=5|r(x)=>P) } F { (r<=5) , (r(x)=>P)} F { r(x)=>P } if(r has a value)then x = get_value(r); F{ P } else (* allocate a closure P in heap and ... *) F{ }

18. Unboxed Channel Scheme • Unboxed channel = channel allocated on register • No memory access to manipulate an unboxed channel • All channels are created as an unboxed channel • An unboxed channel is elevated to a heap-allocated one as necessary

19. Example r = EMPTY_CHANNEL; if (...) { ... } else { r = 5 + VAL_TAG; if (...) { x = r - VAL_TAG; ... } else { ... } ... } r= new_channel(); if(r has a process)then ... else put_value(r, 5); if(r has a value)then x =get_value(r); F{P } else ... ML-like code Corresponding C code Channel allocation and communication on a register

20. 6 8 123 When to allocate a space on heap? two values are sent an unboxed channel is duplicated ??? P1 P2

21. Experimental Results (1/2) • HACL is used as an intermediate language of Schematic [Taura et al. 96] • ML-like program is compiled to assembly-like C • A native code is generated by GNU C compiler • Runtime type checks are omitted • SS20 (HyperSparc 150MHz) • Now implementing on a large-scale SMP

22. Experimental Results (2/2)

23. Related Work (1/2) • Id [Schauser et al. 95], Fleng [Araki et al. 97] • Static scheduling ≒ sequentialization • A does not depend on B ⇒ A|B → A ; B • Pict [Turner 96] • All channel communications need memory operation • A receive (input) expression always allocate a closure whether a value is present or not

24. Related Work (2/2) • StackThreads[Taura et al. 94, 97] • An original proposal of unboxed channel • Linear channel [Kobayashi et al. 96, Igarashi 97] • Linear channel = channel used only once • Some communications for linear channel is statically eliminated • CPS [Appel 92] • A compilation framework for sequential language

25. Conclusion • We proposed a framework compiling process calculus efficiently • Static scheduling • Unboxed channel • A language based on a process calculus is executed only a few times slower than C

26. Schematic [Taura et al. 96] concurrent functional language, concurrent OO language, etc... Pict [Turner 96] HACL process calculus Pi-calculus Surface Languages for Process Calculi surface language intermediate language machine code

27. schedule f(r,x) first Can we schedule f and P statically ??? Difficult. The scheduling pool is still necessary. scheduling stack ≒ a set of schedulable closures A Schedulable Closure and The Scheduling Stack F { f(r, x), P } f(r,x) P