Clinger, W. D., Hartheimer, A. H., and Ost, E. O. Implementation Strategies for Continuations. in Proceedings of the 1988 ACM Conference on Lisp and Functional Programming. ACM, New York, 1988, pp. 124-131.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....active process. When a function returns the current stack frame is removed from the stack and the caller s stack frame, if it is not at the top of the stack, is copied there before control returns to the caller. This is known as the incremental stack heap strategy for implementing continuations [CHO99, CHO88]. 4 Comparing Erlang OTP and ETOS The versions of the systems we have evaluated are Erlang OTP R7B 3 and ETOS 2.4 with Gambit C 4.0 alpha 7. The platform used is a PC with 1.4GHz AMD Athlon, 64KB L1 I cache, 64KB L1 D cache, 256KB L2 cache, 512MB RAM and running Linux kernel 2.4.2 2 and gcc ....

William D. Clinger, Anne H. Hartheimer, and Eric M. Ost. Implementation strategies for continuations. In Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, pages 124-131. ACM, July 1988.

....by all windows of the client s browser. 7. 2 How big are continuations That depends on the complexity of the web application (in terms of embedded functions calls) A continuation may roughly be seen as a copy of the evaluation stack (of course there are far better ways to implement them, see [CHO88, HDB90]) Most often, stacks are not very deep. Moreover, stacks may be implemented as linked activation frames where sharing is not only possible but widely observed [Dan87] We implemented a Scheme interpreter in Java, named PS3I 1 , with full continuations for an educational CDROM 1 ....

William D. Clinger, Anne H. Hartheimer, and Eric M. Ost. Implementation strategies for continuations. In Conference Record of the 1988 ACM Conference on Lisp and Functional Programming, pages 124--131, August 1988.

....talk of efficient programs we are talking about programs with execution times that increase with input size no faster than a constant times the complexity of an optimal program. Second, our efficiency claims depend on the assumption that call cc is not implemented as a control stack copy operation [2, 3] but rather as a cons cell that points to a portion of the heap based control stack. We realize that no production version of Scheme currently does this. Implementing call cc by representing the control states in the heap has constant cost, but procedure calls are slightly more expensive (by a ....

W. D. Clinger, A. H. Hartheimer, and E. M. Ost, "Implementation strategies for continuations," Proc. 1988 ACM Conf. on Lisp and Func. Prog., ACM, New York (1988), pp. 124-131.

....talk of ecient programs we are talking about programs with execution times that increase with input size no faster than a constant times the complexity of an optimal program. 16 Second, our eciency claims depend on the assumption that call cc is not implemented as a control stack copy operation [2, 3] but rather as a cons cell that points to a portion of the heap based control stack. We realize that no production version of Scheme currently does this. Implementing call cc by representing the control states in the heap has constant cost, but procedure calls are slightly more expensive (by a ....

W. D. Clinger, A. H. Hartheimer, and E. M. Ost, \Implementation strategies for continuations," Proc. 1988 ACM Conf. on Lisp and Func. Prog., ACM, New York (1988), pp. 124-131.

....to free stack with the necessary (and then explicit) control links. This technique allows allocating mutable locations in the stack since these locations are not duplicated. evaluation stack i.e. a linked list of activation records; it usually involves some copy for stack based implementation [Clinger 88, Hieb Dybvig Bruggeman 90] 1 Semantical Framework This section presents much of the semantics of a Scheme like language and formalizes our conception of dynamic extent, see also [Steele 90, chapter 3] The term extent refers to a period of time: the lifetime of an entity 2 . Any entity ....

William Clinger, Anne Hartheimer, Implementation Strategies for Continuations, Proceedings of the 1988 ACM Lisp and Functional Programming, Snowbird, Utah, July 1988, pp 124--131.

....the performance tradeoffs between using the heap and using the stack. Jones and Muchnick [13] were among the first authors to examine the language and performance implications of stack vs. heap allocation. Other authors have shown how hybrid heap stack strategies for allocating both continuations [8] and data structures [4] can improve performance. Our work is most closely related to Aiken et al. s work [1] which describes an ML compiler with implicit region operations and to Gay and Aiken s work [12] which describes a compiler for a C like language with explicit region operations. Our work ....

W. D. Clinger, A. H. Hartheimer, and E. M. Ost. Implementation strategies for continuations. In Proceedings of the 1988 ACM Conference on LISP and Functional Programming, pages 124--131, Snowbird, UT, July 1988.

....implementing tail calls correctly and efficiently on a conventional stack. Closure passing style: Lambda notation has often been used to represent the results of closure analysis (this is also called lambda lifting ) 14, 22, 4, 24] Efficient call cc: Many have tried to make call cc efficient [15, 13, 21]. Callee save registers: Dataflow analysis can help decide whether to put variables in caller save or callee save registers [12, 19] We had shown how to represent calleesave registers in continuation passing style [6, 2] but our new algorithm does a much better job of it. Safe space complexity: ....

William D Clinger, Anne H Hartheimer, and Eric M Ost. Implementation strategies for continuations. In 1988 ACM Conference on Lisp and Fucntional Programming, pages 124--131, New York, June 1988. ACM Press.

....activation records. In the presence of continuations, this stack is often implemented as a linked list to facilitate the capture and invocation of continuations as objects. It is also possible to employ a true stack by copying continuations that have been captured before they are modified [7, 5, 3]. With either implementation, it is possible to place a constant bound on the amount of work that must be performed by the continuation operations regardless of the size of the current continuation[17] Subcontinuations can be implemented in a similar manner with little additional overhead. ....

Clinger, William D. and Ost, Eric M. Implementation strategies for continuations. In Proceedings of the 1988 ACM Conference on Lisp and Functional Programming (July 1988) 124--131.

....using a C array and pointer operations. The translation is straightforward and most C compilers optimize this kind of array and pointer arithmetic. Once this decision has been made, it is simple to implement call with current continuation portably using any one of several well known techniques[2, 8]. Both systems distribute the program s executable C code among a set of C procedures called host procedures. Each host procedure contains a set of control points: places in its code that can be the target of a control transfer (i.e. procedure entry points and return points) A procedure object ....

William Clinger, Anne Hartheimer, and Eric Ost. Implementation strategies for continuations. In Proc. ACM Symp. LISP and Functional Progr., pages 124--131, 1988.

....in Scheme. They are created (captured) by means of the call cc function. Scheme continuations have an indefinite extent which confers upon them numerous usages from escape constructs such as catch throw a la Common Lisp, to coroutines [HFW84] They are very powerful but difficult to compile well [CHO88, HD90, JG89] and they pose complex implementation problems. We decided to emphasize the concept of dynamic extent and use the primitives of [QS91] known as splitter, abort and call pc. Furthermore we identify splitter with call de. call de marks the current continuation so that it can be ....

William D. Clinger, Anne H. Hartheimer, and Eric M. Ost. Implementation strategies for continuations. In Conference Record of the 1988 ACM Conference on Lisp and Functional Programming, page 124 131, August 1988.

.... as well, even though they go beyond CPS (i.e. in general, they do not have any CPS counterpart [14] We used Sitaram and Felleisen s implementation [34] 8 At the 1988 Lisp conference, Clinger, Hartheimer, and Ost reported that typically 80 of captured continuations are shared in MacScheme [6]. 9 nqCPS stands for not quite CPS (Lee) and is also known as A normal forms (Sabry Felleisen) monadic normal forms (Hatcliff Danvy) and, maybe more plainly, as (higher order) three address code. 6 Conclusion Continuation based partial evaluation improves over naive partial ....

William Clinger, Anne H. Hartheimer, and Eric M. Ost. Implementation strategies for continuations. In Robert (Corky) Cartwright, editor, Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, pages 124--131, Snowbird, Utah, July 1988.

....fit in the cache. This is borne out by simulation studies of Standard ML of New Jersey [DTM93] on high performance processors. It suggests that activation information and binding environments should be allocated on a stack using compile time analysis [KKR 86] or in a software stack cache [CHO88, WM89, Kel93] Software stack caches can be used in languages like ML and Scheme, where binding environments may be captured by first class procedures and or activation chains may be captured with first class continuations. The cache takes advantage may actually perform better when the two are ....

Will Clinger, Anne Hartheimer, and Erik Ost. Implementation strategies for continuations. In Conference Record of the 1988 ACM Symposium on LISP and Functional Programming, pages 124--131, Snowbird, Utah, July 1988. ACM Press.

....style) AJ89, KH89] Many have tried to make call cc efficient, but this is very hard to achieve in traditional stack based schemes. With an ordinary contiguous stack implementation, the entire stack must be copied on each creation or invocation of a first class continuation. Clinger [CHO88b] and Hieb [HDB90] presented several mixed stack heap strategies intended to support call cc efficiently in the presence of stacks. Their basic idea is to make a stack chunk that holds several stack frames; if this fills, it is linked to another chunk allocated from the heap. This turns to be ....

....are not updated after their initialization, call cc is no more expensive than an ordinary procedure call: the live registers must be written to a closure record, and that is all. There have been mixed stack heap implementations intended to support call cc efficiently in the presence of stacks [CHO88b, HDB90] The basic idea is to make a stack chunk that holds several stack frames; if this fills, it is linked to another chunk allocated from the heap. This turns out to be complicated to implement. Stack chunks require a stack overflow test on every frame, 14 so creation costs three ....

William D Clinger, Anne H Hartheimer, and Eric M Ost. Implementation Strategies for Continuations. In 1988 ACM Conference on Lisp and Functional Programming, pages 124--131, New York, June 1988. ACM Press.

....are not updated after their initialization) call cc is no more expensive than an ordinary procedure call: the live registers must be written to a closure record, and that is all. There have been mixed stack heap implementations intended to support call cc efficiently in the presence of stacks[13, 20]. The basic idea is to make a stack chunk that holds several stack frames; if this fills, it is linked to another chunk allocated from 9 Unfortunately, it has been our experience that memory exceptions are not a tenable means for detecting stack overflow. 20] 10 Proportional to the size of ....

William D Clinger, Anne H Hartheimer, and Eric M Ost. Implementation strategies for continuations. In 1988 ACM Conference on Lisp and Functional Programming, pages 124--131, New York, June 1988. ACM Press.

....it was according to CPS. Observe the duplication of q1 which is still the current continuation of the call to f as well as a part of the reified continuation. This apparent simplicity must not hide the fact that continuations are difficult to compile and implement efficiently as can be seen in [CHO88, HD90, JG89, Mat92]. define (ACPS call cc q1 f) f q1 (lambda (q2 value) resume q1 value) Figure 1: call cc 3 Partial continuations Consider the following function, which uses call cc to perform a premature exit. It receives a list of numbers to multiply: define (multiply list list of numbers) call cc ....

William D. Clinger, Anne H. Hartheimer, and Eric M. Ost. Implementation strategies for continuations. In Conference Record of the 1988 ACM Conference on Lisp and Functional Programming, page 124 131, August 1988.

....are not updated after their initialization) call cc is no more expensive than an ordinary procedure call: the live registers must be written to a closure record, and that is all. There have been mixed stack heap implementations intended to support call cc e#ciently in the presence of stacks (Clinger, Hartheimer, and Ost, 1988; Hieb, Dybvig, and Bruggeman, 1990) The basic idea is to make a stack chunk that holds several stack frames; if this fills, it is linked to another chunk allocated from the heap. This turns out to be complicated to implement. Stack chunks require a stack overflow test on every frame 13 , so ....

Clinger, William D., Anne H. Hartheimer, and Eric M. Ost. 1988 (June). Implementation strategies for continuations. In 1988 ACM Conference on Lisp and Functional Programming, pages 124--131, New York. ACM Press.

.... for instance, if a Scheme implementation S employs heap based allocation of activation records, an implementation of Safe C which may have to interoperate with S cannot use a stack; or, conversely, the Scheme implementations will be forced to use an allocation strategy compatible with a stack [1, 5]. At the other extreme are interfaces like COM [15] which impose few restrictions on language implementations. Safety is to be ensured via sandboxing, using separate address spaces. The interoperation mechanism supports only basic language features, e.g. function invocation and passing of ....

William D Clinger, Anne H Hartheimer, and Eric M Ost. Implementation strategies for continuations. In ACM Conference on Lisp and Functional Programming, pages 124--131, New York, June 1988. ACM Press.

....view of external functions as effect polymorphic without restricting their actual implementations. 6 Related Work and Conclusions The work presented in this paper is mainly inspired by recent research on effect inference [6, 10, 11, 23, 24] efficient implementation of first class continuations [2, 8, 22, 1], monads and modular interpreters [30, 12, 29, 13] typed intermediate languages [7, 26, 20, 17, 16, 3] and foreign function call interface [9, 18] In the following, we briefly explain the relationship of these work with our resource based approach. Effect systems. The idea of using ....

....over a finite set of resources this allows us to take advantage of the effect resource relationship to support advanced compilation strategies. Efficient call cc. Many people have worked on designing various strategies to support efficient implementation of first class continuations [2, 8, 22, 1]. To support a reasonably efficient call cc, compilers today mostly use stack chunks (a linked list of smaller stacks) 2, 8] or they simply heap allocate all activation records [22] Both of these representations are incompatible with those used by traditional languages such as C and C where ....

[Article contains additional citation context not shown here]

W. D. Clinger, A. H. Hartheimer, and E. M. Ost. Implementation strategies for continuations. In 1988 ACM Conference on Lisp and Functional Programming, pages 124--131, New York, June 1988. ACM Press.

....results in smaller indirect costs from garbage collection, cache misses, and page faults. Our approach does not suffer from some of the limitations of the heap based approach, such as the inability to reuse frames and the inability to stack allocate objects with dynamic extent. Clinger, et al. [3], argue that a hybrid stack heap mechanism may be most appropriate for Scheme and Smalltalk. Their mechanism provides for the frames to be allocated on a stack and moved into a heap allocated linked list when a continuation is created. This list remains in the heap indefinitely and the frames in ....

William D. Clinger, Anne H. Hartheimer, and Eric M. Ost, "Implementation Strategies for Continuations," Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, July 1988, 124--131.

....usage The standard stack discipline is not an obstacle to implementing longlived environments or continuations. In most cases, the environment and continuation passed to a procedure are removed from the stack when the procedure returns. If they need to be preserved they may be copied to a heap [Clinger 88] Copying requires that each environment and continuation include an indication of its size. For continuations, this may be either unnecessary, if continuations need not be preserved, or it may be found at a known offset from the saved program counter and not take up any space on the stack. The ....

....remain in the heap) Checking for stack underflow during procedure returns can be avoided by placing a special continuation at the base of the stack which copies the next continuation from the heap onto the stack. Locality considerations might keep the cost of copying fairly low, as argued in [Clinger 88] This is certainly the most attractive strategy for languages that already require a heap. 4 Saving Environments All of the languages which were given as examples of properly tail recursive languages are also lexically scoped and allow procedures to escape upwards. This means that a local ....

[Article contains additional citation context not shown here]

William D Clinger, Anne H Hartheimer, and Eric M Ost. Implementation strategies for continuations. In Proceedings Record of the 1988 ACM Symposium on Lisp and Functional Programming, ACM, 1988.

No context found.

William Clinger, Anne Hartheimer, and Eric Ost. Implementation strategies for continuations. In Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, pages 124--131.

....were allocated in the heap in the first place. Later, when the cache underflows or a continuation is reinstated, a single frame is restored from the heap and placed in the cache. This stack cache scheme is known as the incremental stack heap strategy and is described more fully by Clinger et al. [6]. In Larceny, the stack cache is also flushed before every garbage collection, since having all live data in the heap simplifies the garbage collector. The performance impact of this, if any, is unclear, and would appear to depend very heavily on the codes being run. It is important to observe ....

William Clinger, Anne Hartheimer, and Eric Ost. Implementation Strategies for Continuations. Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, 124-131.

No context found.

Clinger, W. D., Hartheimer, A. H., and Ost, E. O. Implementation Strategies for Continuations. in Proceedings of the 1988 ACM Conference on Lisp and Functional Programming. ACM, New York, 1988, pp. 124-131.

No context found.

W. Clinger, A. H. Hartheimer, and E. M. Ost. Implementation strategies for continuations. In R. C. Cartwright, editor, Proceedings of the

No context found.

Clinger, W., Hartheimer, A., and Ost, E. "Implementation strategies for continuations". Proc. LFP, 1988, 124-131.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC