科研速览 · Science Skim继续刷下去 · Keep skimming →
◆ INTERNATIONAL JOURNAL OF COMPUTER SCIENCE AND MATHEMATICAL THEORY E-ISSN2026-08-24· Computer science

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

A.P. Adewole

原始摘要(英文原文)· Original abstract
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 languages: C, Java, Python, and Haskell — examining activation record structures, memory allocation strategies, scoping mechanisms, and closure support. The findings reveal that C uses a hardware-centric stack model that emphasises memory predictability and efficiency but does not permit closures or nested subprograms. Through the Java Virtual Machine, Java abstracts this approach, adding partial closure support and type safety at the expense of extra overhead. By allocating heapbased frame objects, Python completely deviates from the stack model, allowing for full closure and nested subprogram support at the expense of increased memory overhead and slower execution speeds. The most drastic change is found in Haskell, which uses heapallocated thunks and graph reduction to provide lazy evaluation. This allows for sophisticated functional programming patterns at the cost of a non-intuitive execution model that diverges fundamentally from traditional call-and-return semantics. These findings offer practical guidance for developers selecting languages for performance-critical or feature-rich applications, and for language designers making foundational decisions about runtime memory management strategies.
读原文 · Read the paper ↗

AI 追问PRO

登录后使用 AI 追问

讨论区

登录后参与讨论

相关论文 · Related

Subprogram Call Implementation and Runtime Stack Management: A Comparative Analysis of C, Java, Python, and Haskell — 科研速览 Science Skim