Skip to content
Book Open access

Regions as Continuation Marks

Aug 2026 · Proceedings of the 27th ACM SIGPLAN International Workshop on Scheme and Functional Programming · 0 citations · 6 references

TL;DR

A translation from regions to continuation marks is provided and what this connection could entail for both languages with region-based memory management and the authors' favourite Schemes (and Racket) with continuation marks is theorized.

Abstract

Region-based memory management started as a compiler pass to optimize Standard ML programs. Garbage collection was expensive, manual memory management was unsafe, and so instead one infers a stack of memory regions to enable the compiler to insert explicit memory allocation and deallocation instructions. The result of region inference is a ML program with lexically-scoped regions. Unfortunately, the stack-based region inference interferes with the correct behaviour of tail recursion: that tail recursion must run in constant space, and much work was required to correct their behaviour in practice. We show a formal connection between these lexical regions and continuation marks, which elucidates the behaviour of regions with respect to tail calls, and provide insights into possible implementation techniques and new semantics. Continuation marks enable placing a value on the dynamic program frame, and were designed and implemented to behave correctly with respect to tail recursion. We provide a translation from regions to continuation marks and theorize what this connection could entail for both languages with region-based memory management and our favourite Schemes (and Racket) with continuation marks.

Read PDF

Similar papers

Preprint Sep 2026

RPyForth: Exposing a Call-Shared Data Stack to a Meta-Tracing JIT Compiler

Forth is a concatenative language whose words share one data stack across calls, with a depth and call effects that need not be known before execution. That leaves a meta-tracing JIT compiler with no stack location it can name: a cell is reached through the stack pointer, so its accesses stay in the compiled code, and...

Yusuke Izawa, Kota Hakamada · 0 citations
Open access Aug 2026

Subprogram Call Implementation and Runtime Stack Management: A Comparative Analysis of C, Java, Python, and Haskell

Programming languages differ significantly in how subprogram calls and runtime stack management are implemented, which reflects underlying variations in execution models, design philosophies, and performance objectives. This study systematically compares subprogram call implementation across four widely used languag...

A. Adewole · 0 citations
Book Open access Sep 2026

Support Local Variables

Ruby is a dynamically typed and object-oriented programming language. Its primary implementation, CRuby, contains a bytecode virtual machine and a mature lazy basic block versioning (LBBV) just-in-time (JIT) compiler called YJIT. In order to both implement more advanced optimizations than YJIT supports and also encoura...

Maxwell Bernstein, Takashi Kokubun, Aaron Patterson et al. · 0 citations
Book Open access Sep 2026

Quantifying the Code-Size Overhead of eBPF JIT Compilation

eBPF allows user-defined programs to safely extend Linux kernel functionality at runtime, but its final machine code comes from a compilation pipeline that differs from native targets, and how efficient that pipeline is has no clear reference point. Our work constructs one: using the standard LLVM x86 backend as an app...

Hoang Duong, Hao Sun, Zhen-Dong Su · 0 citations
Open access Aug 2026

LoCalMem: Type-Directed Adaptive Serialization for Location- and Content-Addressable Memory

Functional programming languages support non-destructive updates via structural sharing, creating a funda-mental tradeoff in memory representation: pointer-based heaps preserve sharing but degrade layout locality, while serialized heaps prioritize locality at the cost of duplication. Gibbon addresses this tradeoff by u...

Mike Rainey, M. Borkowski, Michael Vollmer et al. · 0 citations
#artificial intelligence Preprint Sep 2026

Dynamic Adaptation of the LLM Context for Generating Routines with Coupled Semantics

LLM-based code generation fails when correctness depends on execution-dependent coupling: the meaning of one routine is defined by the runtime behavior of another, a relationship that cannot be resolved from textual descriptions alone. This limitation, which we call static binding, is not confined to explicitly coupled...

Gnaneswar Villuri, Hashmath Shaik, Alex Doboli · 1 citation

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.