ICOOOLPS '23: "Towards Reliable Memory Management ..."
Towards Reliable Memory Management for Python Native Extensions
Joannah Nanjekye, David Bremner, and Aleksandar Micic
(University of New Brunswick, Canada; IBM, Canada)
Many programming languages provide a C interface as a foreign function interface (FFI) for C developers to access the language, the Python language being one of these languages. Over the years, the Python C API has grown to be a challenge for the evolution of the Python ecosystem. In this paper, we implement a new Python FFI, we call CyStck, by combining a stack and light-weight handles, to support efficient garbage collection (GC) in Python native extensions. CyStck introduces execution time overhead while copying the fewest bytes for all benchmarks across the CPython boundary compared to the CPython API and HPy respectively. We also implemented a tool to automate the migration of extensions from the CPython C API to CyStck using advanced pattern matching and static analysis, with a success rate as high as 90% in some workloads.
@InProceedings{ICOOOLPS23p15,
author = {Joannah Nanjekye and David Bremner and Aleksandar Micic},
title = {Towards Reliable Memory Management for Python Native Extensions},
booktitle = {Proc.\ ICOOOLPS},
publisher = {ACM},
pages = {15--26},
doi = {10.1145/3605158.3605849},
year = {2023},
}
Publisher's Version
Published Artifact
Artifacts Available
ICOOOLPS '23: "A Retrospective on Julia (Invited ..."
A Retrospective on Julia (Invited Talk)
Benjamin Chung
(University of Washington, USA; Northeastern University, USA)
The Julia programming language was designed around a lofty objective: to let scientists and researchers write both dynamic scripts and fast libraries in the same language while also facilitating decoupling and abstraction. Moreover, Julia wanted to do this with a scrappy academic development team of three people and in the span of about two years. I'll talk about the decisions that Julia made early on to meet this goal, reflect on how those decisions have aged as the language (and ecosystem around it) matured, and about some key lessons that other languages might be able to learn from Julia's experience.
@InProceedings{ICOOOLPS23p2,
author = {Benjamin Chung},
title = {A Retrospective on Julia (Invited Talk)},
booktitle = {Proc.\ ICOOOLPS},
publisher = {ACM},
pages = {2--2},
doi = {10.1145/3605158.3608956},
year = {2023},
}
Publisher's Version
ICOOOLPS '23: "Lazy Code Transformations ..."
Lazy Code Transformations in a Formally Verified Compiler
Léo Gourdin
(Université Grenoble Alpes, France; CNRS, France; Grenoble INP, France; VERIMAG, France)
Translation validation verifies the results of an untrusted translator—called an oracle—at the compiler’s runtime using a validator. This approach enables validating intricate optimizations without having to prove them directly. Parametrizing such a validator with hints provided by oracles greatly simplifies its integration within a formally verified compiler—such as CompCert. However, generating those hints requires adapting state-of-the-art optimizations.
The co-design of a validation framework supporting a class of optimizations led us to improve the Lazy Code Motion (LCM) and Lazy Strength Reduction (LSR) data-flow algorithms of Knoop, Rüthing, and Steffen. We propose an efficient implementation in OCaml combining both LCM and LSR, operating over basic-blocks, and whose result is checked by a Coq-verified validator. We show how to generate invariant annotations from the data-flow equations as hints for the defensive validation, and we introduce several algorithmic refinements w.r.t. the original papers.
Our solution is fully integrated within CompCert, and to the best of our knowledge, it is the first formally verified strength-reduction of loop-induction variables.
@InProceedings{ICOOOLPS23p3,
author = {Léo Gourdin},
title = {Lazy Code Transformations in a Formally Verified Compiler},
booktitle = {Proc.\ ICOOOLPS},
publisher = {ACM},
pages = {3--14},
doi = {10.1145/3605158.3605848},
year = {2023},
}
Publisher's Version
Info
ICOOOLPS '23: "Towards Reliable Memory Management ..."
Towards Reliable Memory Management for Python Native Extensions
Joannah Nanjekye, David Bremner, and Aleksandar Micic
(University of New Brunswick, Canada; IBM, Canada)
Many programming languages provide a C interface as a foreign function interface (FFI) for C developers to access the language, the Python language being one of these languages. Over the years, the Python C API has grown to be a challenge for the evolution of the Python ecosystem. In this paper, we implement a new Python FFI, we call CyStck, by combining a stack and light-weight handles, to support efficient garbage collection (GC) in Python native extensions. CyStck introduces execution time overhead while copying the fewest bytes for all benchmarks across the CPython boundary compared to the CPython API and HPy respectively. We also implemented a tool to automate the migration of extensions from the CPython C API to CyStck using advanced pattern matching and static analysis, with a success rate as high as 90% in some workloads.
@InProceedings{ICOOOLPS23p15,
author = {Joannah Nanjekye and David Bremner and Aleksandar Micic},
title = {Towards Reliable Memory Management for Python Native Extensions},
booktitle = {Proc.\ ICOOOLPS},
publisher = {ACM},
pages = {15--26},
doi = {10.1145/3605158.3605849},
year = {2023},
}
Publisher's Version
Published Artifact
Artifacts Available
ICOOOLPS '23: "Towards Reliable Memory Management ..."
Towards Reliable Memory Management for Python Native Extensions
Joannah Nanjekye, David Bremner, and Aleksandar Micic
(University of New Brunswick, Canada; IBM, Canada)
Many programming languages provide a C interface as a foreign function interface (FFI) for C developers to access the language, the Python language being one of these languages. Over the years, the Python C API has grown to be a challenge for the evolution of the Python ecosystem. In this paper, we implement a new Python FFI, we call CyStck, by combining a stack and light-weight handles, to support efficient garbage collection (GC) in Python native extensions. CyStck introduces execution time overhead while copying the fewest bytes for all benchmarks across the CPython boundary compared to the CPython API and HPy respectively. We also implemented a tool to automate the migration of extensions from the CPython C API to CyStck using advanced pattern matching and static analysis, with a success rate as high as 90% in some workloads.
@InProceedings{ICOOOLPS23p15,
author = {Joannah Nanjekye and David Bremner and Aleksandar Micic},
title = {Towards Reliable Memory Management for Python Native Extensions},
booktitle = {Proc.\ ICOOOLPS},
publisher = {ACM},
pages = {15--26},
doi = {10.1145/3605158.3605849},
year = {2023},
}
Publisher's Version
Published Artifact
Artifacts Available
ICOOOLPS '23: "Deegen: A Meta-compiler Approach ..."
Deegen: A Meta-compiler Approach for High Performance VMs at Low Engineering Cost (Invited Talk)
Haoran Xu
(Stanford University, USA)
Building a high-performance VM for a dynamic language has traditionally required a huge amount of time, money, and expertise. To reduce the high engineering cost, we present Deegen, a meta-compiler that generates a high-performance VM automatically from a semantical description of the bytecodes. Currently, Deegen is capable of automatically generating an optimized interpreter and baseline JIT compiler. This allows the user get a high-performance VM for their own language at an engineering cost similar to writing an interpreter. To demonstrate Deegen's capability in the real world, we implemented LuaJIT Remake (LJR), a standard-compliant VM for Lua 5.1. Across a variety of benchmarks, we demonstrated that LJR's interpreter significantly outperforms LuaJIT's interpreter, and LJR's baseline JIT generates high-quality code with a negligible compilation cost.
@InProceedings{ICOOOLPS23p1,
author = {Haoran Xu},
title = {Deegen: A Meta-compiler Approach for High Performance VMs at Low Engineering Cost (Invited Talk)},
booktitle = {Proc.\ ICOOOLPS},
publisher = {ACM},
pages = {1--1},
doi = {10.1145/3605158.3607815},
year = {2023},
}
Publisher's Version