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.
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...
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· International Journal of Com...· 0 citations
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.· Proceedings of the 18th ACM...· 0 citations
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· Proceedings of the 4th Works...· 0 citations
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.· Proc. ACM Program. Lang.· 0 citations
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.