Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

LitmusKt: Concurrency Stress Testing for Kotlin

Denis Lochmelis, Evgenii Moiseenko, Yaroslav Golubev, Anton Podkopaev

TL;DR

LitmusKt addresses the challenge of verifying Kotlin concurrency across multiplatform targets by providing a DSL-driven litmus-testing framework with a Native custom runner and a JVM path using jcstress, enabling cross-platform behavior comparison. It contributes a first-of-its-kind tool for Kotlin concurrency litmus testing, discovers and fixes Kotlin/Native bugs such as unsafe publication, and integrates into the Kotlin CI pipeline, making it practical for researchers and practitioners. The work demonstrates how multiplatform concurrency semantics can be probed across platforms and highlights platform-specific weaknesses and the need for formal memory models. The approach offers a scalable way to expose subtle concurrency bugs and supports broader future work in runtime optimizations and false-sharing mitigation.

Abstract

We present LitmusKt - the first tool for litmus testing concurrent programs in Kotlin. The tool's novelty also lies in the fact that Kotlin is a multiplatform language, i.e., it compiles into multiple platforms, which means that the concurrency has to be tested on several of them. Our tool allows writing litmus tests in a single custom DSL, and these tests are then run in Kotlin/Native and Kotlin/JVM, two main platforms for concurrent programming in Kotlin. Using LitmusKt, we discovered novel bugs in the Kotlin compiler, which we then fixed and they are no longer present. Moreover, LitmusKt was integrated into the CI pipeline for Kotlin. LitmusKt is available on GitHub: https://github.com/JetBrains-Research/litmuskt. The demo is available on YouTube: https://youtu.be/oWCZp_Huwss.

LitmusKt: Concurrency Stress Testing for Kotlin

TL;DR

LitmusKt addresses the challenge of verifying Kotlin concurrency across multiplatform targets by providing a DSL-driven litmus-testing framework with a Native custom runner and a JVM path using jcstress, enabling cross-platform behavior comparison. It contributes a first-of-its-kind tool for Kotlin concurrency litmus testing, discovers and fixes Kotlin/Native bugs such as unsafe publication, and integrates into the Kotlin CI pipeline, making it practical for researchers and practitioners. The work demonstrates how multiplatform concurrency semantics can be probed across platforms and highlights platform-specific weaknesses and the need for formal memory models. The approach offers a scalable way to expose subtle concurrency bugs and supports broader future work in runtime optimizations and false-sharing mitigation.

Abstract

We present LitmusKt - the first tool for litmus testing concurrent programs in Kotlin. The tool's novelty also lies in the fact that Kotlin is a multiplatform language, i.e., it compiles into multiple platforms, which means that the concurrency has to be tested on several of them. Our tool allows writing litmus tests in a single custom DSL, and these tests are then run in Kotlin/Native and Kotlin/JVM, two main platforms for concurrent programming in Kotlin. Using LitmusKt, we discovered novel bugs in the Kotlin compiler, which we then fixed and they are no longer present. Moreover, LitmusKt was integrated into the CI pipeline for Kotlin. LitmusKt is available on GitHub: https://github.com/JetBrains-Research/litmuskt. The demo is available on YouTube: https://youtu.be/oWCZp_Huwss.
Paper Structure (9 sections, 3 figures, 3 tables)

This paper contains 9 sections, 3 figures, 3 tables.

Table of Contents

  1. Introduction
  2. Implementation
  3. Example of a LitmusKt Test
  4. Kotlin/Native Test Runner
  5. Kotlin/JVM Test Runner Based on jcstress
  6. Summary.
  7. Analysis
  8. Future work
  9. Conclusion

Figures (3)

  • Figure 1: Store Buffering litmus test, a sample program that demonstrates weak behavior.
  • Figure 2: A schematic of the LitmusKt test running process, using Store Buffering as an example. One gray rectangle represents a single test state. We allocate an array of them. Then, test threads sequentially execute their functions on this array of states. The threads also regularly synchronize on barriers.
  • Figure 3: The Unsafe Publication (UPUB) test.