Benjamin Kushigian

dblp:242/6261 · DBLP profile ↗
← Back
3ranked-venue papers
1as first author
3since 2021 · last 2024
0009-0009-2504-1582ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 1 first-author · 3 since 2021Systems, architecture and hardware · 1 · 1 since 2021
YearPublicationVenuePosition
2024 FPGA Technology Mapping Using Sketch-Guided Program Synthesis
abstract
FPGA technology mapping is the process of implementing a hardware design expressed in high-level HDL (hardware design language) code using the low-level, architecture-specific primitives of the target FPGA. As FPGAs become increasingly heterogeneous, achieving high performance requires hardware synthesis tools that better support mapping to complex, highly configurable primitives like digital signal processors (DSPs). Current tools support DSP mapping via handwritten special-case mapping rules, which are laborious to write, error-prone, and often overlook mapping opportunities. We introduce Lakeroad, a principled approach to technology mapping via sketch-guided program synthesis. Lakeroad leverages two techniques---architecture-independent sketch templates and semantics extraction from HDL---to provide extensible technology mapping with stronger correctness guarantees and higher coverage of mapping opportunities than state-of-the-art tools. Across representative microbenchmarks, Lakeroad produces 2--3.5× the number of optimal mappings compared to proprietary state-of-the-art tools and 6--44× the number of optimal mappings compared to popular open-source tools, while also providing correctness guarantees not given by any other tool.
Gus Henry Smith, Benjamin Kushigian, Vishal Canumalla, Andrew Cheung, Steven Lyubomirsky, Sorawee Porncharoenwase, René Just, Gilbert Louis Bernstein, Zachary Tatlock
ASPLOS (2)2
2024 Using Mutation Testing To Improve and Minimize Test Suites for Smart Contracts
abstract
This paper presents a successful industrial case study on the application of mutation testing to evaluate and improve test suites for smart contracts. ERCx is a comprehensive, hand-written test suite and framework for smart contract testing, created by Runtime Verification. Despite its thoroughness, hand-written tests can miss edge cases. To address this, we employed mutation testing, which introduces small, syntactic changes, known as mutants, to the program. Mutants that go undetected by the test suite highlight its potential weaknesses, and by presenting them as testing goals, mutation testing helps developers iteratively improve their test suites. In this study, we used mutation testing to expand the ERCx test suite with five new test cases, including one potential vulnerability identified as critical by the ERCx developers. We also developed a test redundancy metric by analyzing pairwise correlation of test data on mutants; we used this redundancy metric to minimize the test suite by removing redundant tests. Finally, we ran both the full and minimized test suites on 106 real-world, faulty ERC-20 contracts to compare the suites' effectiveness and efficiency. Our findings reveal that although the minimized test suite has systematically lower running times compared to the full suite, it still detected faults in 105 of the 106 real-world tokens, retaining nearly all of the full suite's fault-detection capability.
Enzo Nicourt, Benjamin Kushigian, Chandrakana Nandi, Yliès Falcone
ICST2
2024 Equivalent Mutants in the Wild: Identifying and Efficiently Suppressing Equivalent Mutants for Java Programs
abstract
The presence of equivalent mutants has long been considered a major obstacle to the widespread adoption of mutation analysis and mutation testing. This paper presents a study on the types and prevalence of equivalent mutants in real-world Java programs. We conducted a ground-truth analysis of 1,992 mutants, sampled from 7 open source Java projects. Our analysis identified 215 equivalent mutants, which we grouped based on two criteria that describe why the mutants are equivalent and how challenging their detection is. From this analysis, we observed that (1) the median equivalent mutant rate across the 7 projects is 2.97%; (2) many equivalent mutants are caused by common programming patterns and their detection is not much more complex than structural pattern matching over an abstract syntax tree. Based on the findings of our ground-truth analysis, we developed Equivalent Mutant Suppression (EMS), a technique that comprises 10 efficient and targeted analyses. We evaluated EMS on 19 open- source Java projects, comparing the effectiveness and efficiency of EMS to two variants of Trivial Compiler Equivalence (TCE), the current state of the art in equivalent mutant detection. Additionally, we analyzed all 9,047 equivalent mutants reported by any tool to better understand the types and frequencies of equivalent mutants found. Overall, EMS detects 8,776 equivalent mutants within 325 seconds; TCE detects 2,124 equivalent mutants in 2,938 hours.
Benjamin Kushigian, Samuel J. Kaufman, Ryan Featherman, Hannah Potter, Ardi Madadi, René Just
ISSTA1