About

Brian Demsky is a professor in the Computer Science Department at the University of California, Irvine. His current research interests include software reliability, security, software engineering, compilation, parallel software, program analysis, and program understanding. He received his B.S. degrees in Physics and Electrical Engineering from the University of Texas, Austin in 1998, his M.S. degree in Computer Science from MIT in 2001, and his Ph.D. degree in Computer Science from MIT in 2006.

Research topics

• Computer Science
• Computer Security
• Embedded system
• Telecommunications
• Operating system
• Programming language
• Engineering
• Parallel computing
• Human–computer interaction
• Computer hardware
• Computer network
• Internet privacy

Selected publications

• CXLMC: Model Checking CXL Shared Memory Programs

  2026-03-10

  articleOpen accessSenior author

  Compute Express Link (CXL) shared memory is an emerging industry standard that will allow for cache coherent sharing of remote memory between many machines. Memory devices will contain large amounts of DRAM that can be shared by many machines in a CXL cluster. This will enable software running on clusters of computers to use shared memory to communicate more efficiently and to share important data between these machines.

  PublisherDOI

• Artifact for the paper "CXLMC: Model Checking CXL Shared Memory Programs"

  Zenodo (CERN European Organization for Nuclear Research) · 2026-01-10

  otherOpen accessSenior author

  cxlmc-evaluation.zip contains the Dockerfile, source code for CXLMC, its compiler pass, its benchmarks and the scripts for running the evaluation. cxlmc-artifact-image.tar.gz contains a pre-built docker image, so the time to build the docker image can be avoided. This version fixes the incorrect CXLMCPass commit used in version 3.

  PublisherDOI

• Automated Insertion of Flushes and Fences for Persistency

  2025-11-16 · 1 citations

  articleSenior author

  CXL shared memory and persistent memory allow the contents of memory to persist beyond crashes. Stores to persistent or CXL memory are typically not immediately made persistent; developers must manually flush the corresponding cache lines to force the data to be written to the underlying storage. Correctly using flush and fence operations is known to be challenging. While state-of-the-art tools can find missing flush instructions, they often require bug-revealing test cases. No existing tools can ensure the absence of missing flush bugs.In this paper, we present PMRobust, a compiler that automatically inserts flush and fence operations to ensure that code using persistent memory is free from missing flush and fence bugs. PMRobust employs a novel static analysis with optimizations that target newly allocated objects. We have evaluated PMRobust on persistent memory libraries and several persistent memory data structures and measured a geometric mean overhead of 0.26% relative to the original benchmarks with hand-placed flush and fence operations.

  PublisherDOI

• GenC2Rust: Towards Generating Generic Rust Code from C

  2025-04-26 · 4 citations

  articleSenior author

  Rust provides an exciting combination of strong safety guarantees and high performance. Many new systems are being implemented in Rust. Nevertheless, there is a large body of existing C code that could greatly benefit from Rust's safety guarantees. Unfortunately, the manual effort required to rewrite C code into Rust is often prohibitively expensive. Researchers have explored tools to assist developers in trans-lating legacy C code into Rust code. However, the mismatch between C abstractions and idiomatic Rust abstractions makes it challenging to automatically utilize Rust's language features, resulting in non-idiomatic Rust code that requires extensive manual effort to further refactor. For example, existing tools often fail to map polymorphic uses of void pointers in C to Rust's generic pointers. In this paper, we present a translation tool, GenC2Rust, that translates non-generic C code into generic Rust code. GenC2Rust statically analyzes the use of void pointers in the C program to compute the typing constraints and then retypes the parametric polymorphic void pointers into generic pointers. We conducted an evaluation of GenC2Rust across 42 C programs that vary in size and span multiple domains to demonstrate its scalability as well as correctness. We discovered GenC2Rust has translated 4,572 void pointers to use generics. We also discuss the limiting factors encountered in the translation process.

  PublisherDOI

• Towards Verifying Crash Consistency

  Proceedings of the ACM on Programming Languages · 2025-10-09

  articleOpen accessSenior author

  Compute Express Link (CXL) memory sharing, persistent memory, and other related technologies allow data to survive crash events. A key challenge is ensuring that data is consistent after crashes such that it can be safely accessed. While there has been much work on bug-finding tools for persistent memory programs, these tools cannot guarantee that a program is crash-consistent. In this paper, we present a language, CrashLang, and its type system, that together guarantee that well-typed data structure implementations written in CrashLang are crash-consistent. CrashLang leverages the well-known commit-store pattern in which a single store logically commits an entire data structure operation. In this paper, we prove that well-typed CrashLang programs are crash-consistent, and provide a prototype implementation of the CrashLang compiler. We have evaluated CrashLang on five benchmarks: the Harris linked list, the Treiber stack, the Michael–Scott queue, a Read-Copy-Update binary search tree, and a Cache-Line Hash Table. We experimentally verified that each implementation correctly survives crashes.

  PublisherDOI

• FlowProf: Profiling Multi-threaded Programs using Information-Flow

  2024-02-17

  articleOpen accessSenior author

  Amdahl's law implies that even small sequential bottlenecks can seriously limit the scalability of multi-threaded programs. To achieve scalability, developers must painstakingly identify sequential bottlenecks in their program and eliminate these bottlenecks by either changing synchronization strategies or rearchitecting and rewriting any code with sequential bottlenecks. This can require significant effort by the developer to find and understand how to fix sequential bottlenecks. To address the issue, we bring a new tool, information flow, to the problem of understanding sequential bottlenecks. Information flow can help developers understand whether a bottleneck is fundamental to the computation, or merely an artifact of the implementation.

  PublisherOA PDFDOI

• Yashme: detecting persistency races

  2022-02-22 · 16 citations

  articleOpen accessSenior author

  Persistent memory (PM) or Non-Volatile Random-Access Memory (NVRAM) hardware such as Intel’s Optane memory product promises to transform how programs store and manipulate information. Ensuring that persistent memory programs are crash consistent is a major challenge. We present a novel class of crash consistency bugs for persistent memory programs, which we call persistency races. Persistency races can cause non-atomic stores to be made partially persistent. Persistency races arise due to the interaction of standard compiler optimizations with persistent memory semantics.

  PublisherOA PDFDOI

• Stateful Dynamic Partial Order Reduction for Model Checking Event-Driven Applications that Do Not Terminate

  Lecture notes in computer science · 2022-01-01

  preprintOpen access
  PublisherOA PDFDOI

• Checking robustness to weak persistency models

  2022-06-02 · 11 citations

  articleOpen accessSenior author

  Persistent memory (PM) technologies offer performance close to DRAM with persistence. Persistent memory enables programs to directly modify persistent data through normal load and store instructions bypassing heavyweight OS system calls for persistency. However, these stores are not made immediately made persistent, the developer must manually flush the corresponding cache lines to force the data to be written to persistent memory. While state-of-the-art testing tools can help developers find and fix persistency bugs, prior studies have shown fixing persistency bugs on average takes a couple of weeks for PM developers. The developer has to manually inspect the execution to identify the root cause of the problem. In addition, most of the existing state-of-the-art testing tools require heavy user annotations to detect bugs without visible symptoms such as a segmentation fault.

  PublisherOA PDFDOI

• Replication Package for Article: Yashme: Detecting Persistency Races

  Artifact Digital Object Group · 2022-02-18

  datasetSenior author
  PublisherDOI

Recent grants

• SHF: Small: Tool Support for Verifiably-Robust Software

  NSF · $500k · 2012–2017

• SaTC: CORE: Medium: Sentinel: Constructing Secure Smart Home IoT Systems via Managed Communications

  NSF · $970k · 2017–2022

• CAREER: Language Features for Robust Software

  NSF · $466k · 2009–2015

• SHF: Small: Information-Flow-Based Profiling of Concurrent Applications

  NSF · $516k · 2020–2025

• Collaborative Research: Applying Hardware-Inspired Methods for Multi-Core Software Design

  NSF · $462k · 2007–2012

Frequent coauthors

• Guoqing Xu

  University of California, Los Angeles

  17 shared

• Martin Rinard

  Massachusetts Institute of Technology

  13 shared

• Rahmadi Trimananda

  9 shared

• Alokika Dash

  Irvine Valley College

  9 shared

• Yong hun Eom

  9 shared

• Shan Lu

  Microsoft (United States)

  8 shared

• James C. Jenista

  University of California, Irvine

  8 shared

• Khanh Nguyen

  7 shared