Computer Science
System Software

Open Projects

For Master's theses, Bachelor's theses or for Software Engineering projects in the Master's program

(Most topics can be adapted in scale to fit any of the above categories)

Filter by:
  • Garbage Collector Fuzzing for GraalVM Native Image (Fuzzing, Garbage Collection, GraalVM Native Image, Java)
    Defects in a garbage collector implementation can lead to subtle issues like memory corruption that are not noticed until some time after they initially occurred. Therefore, these defects are hard to find, reproduce or debug.
    The goal of this project is to create an event-based garbage collector fuzzer, similar to [1], for GraalVM Native Image [2, 3]. The fuzzer generates random events (e.g., allocate an object, write a reference, perform a collection, ...). These events get executed within Native Image. When the execution fails, the event sequence should automatically get reduced to a smaller subset that still reproduces the issue.
    GraalVM Native Image is primarily implemented in Java, so Java is also the main programming language that will be used in this project. Additionally, it is necessary to work with pointers and native memory.
  • Truffle-Interpreter for Lua (Lua, Interpreters, Compilers, Java, Concurrency)
    Lua is a simple lightweight programming language, that is used as an embedded scripting language in a whole host of applications ranging from Apache HTTP Servers all the way to Roblox. Its simplicity also makes it a useful tool to learn about language implementations and interpreters.
    The Truffle language implementation framework is a library that aims to make writing a fast lanugage implementaiton as easy as possible. It provides a domain specific language for implementing interpreters, which are then used to compile the guest language just in time, to achieve great peak performance.
    This project is about extending an existing implementation of Lua on the Truffle bytecode DSL to add language features that are missing from the current implementation and improve performance. Here are a few ideas that can be combined or refined to be a suitable project:
    • Arbitrary gotos: Truffle's bytecode DSL only permits forward jumps, but using Lua's goto keyword, users could build arbitrary control flow, including irriducible (multientry) loops. To enable this feature, one would need to transform these arbitrary gotos into loops and conditional branches.
    • Fast sequential storage: Similar to JavaScript, Lua's objects are associative arrays. Storing elements with ascending integer indices is therefore rather inefficient when done naively. The goal is to implement a storage strategy mirroring the reference implementation of Lua to allow for faster handling of array-style tables.
    • Tail calls: Lua supports proper tailcalls, meaning calls that do not build up the stack. This allows for infinite recursion without running into stack overflows. Truffle does not support tailcalls yet. The goal for this project would be to hack a way to prevent stack build-up in a chain of tailcalls without impacting the performance of regular calls.
    • Coroutines: Although Lua does not support true concurrency, it does allow collaborative multithreading. Threads can yield execution voluntarily and resuming a thread blocks until that one yields. This is the same underlying mechanism as the one used for Java's Virtual Threads. The goal is to implement coroutines in Lua, either with the low-level API used for Virtual Threads, or with platform threads and proper locking.
  • Project MegaSlop: Use LLMs to Generate Large Codebases for Performance Tuning for Modern Runtime Systems (Python, JavaScript, LLMs, Prompting)
    In the future, lots of code may be LLM-generated, and follow different engineering principles than human-written code. For example, it is likely that codebases of modern applications will be significantly larger, with more boilerplate and code duplication. Unfortunately, modern runtime systems that use just-in-time compilation are not yet ready for such codebases. The goal of this project is to construct an approach that allows us to generate large codebases reliably using LLMs. These codebases should resemble real-world application code, but do not have to be functionally correct. Instead, it is sufficient that we can construct them in a way that much of the code is executable to trigger the runtime system's optimizations and identify performance bottlenecks.
  • ReBenchDB: Continuous Performance Testing with GitHub/GitLab CI (Benchmarking, Performance, TypeScript, PostgreSQL, Git, GitHub/GitLab APIs)
    Performance often takes a backseat for developing applications. One reason is probably that measuring and tracking performance it is rather inconvenient and there are no standardized tools. Many big projects from Google, Oracle, Mozilla, and Microsoft have their own custom tools. However, they rarely suite small projects and researchers. ReBenchDB is an open source tool that can be used to track the performance of an application, for instance to see the benefit of optimizations of a language implementation over time. The goal of this project is to expand ReBenchDB, make it more flexible, so that it performance testing can become a natural part of modern development processes. Concrete project ideas include:
    • Tracking Machine Specifications: benchmark machines change over time, their software changes, perhaps some hardware gets replaced, or some security update disables a feature relevant for performance. All this makes it hard to know whether we can compare results over time. By tracking these changes, we can help the user and visualize the changes right in the performance comparisons.
    • 100 little things: instead of approach a single big goal, we could improve the overall usability of ReBenchDB by working an all the small annoyances and simply make it better.
    • Customizable performance comparisons: currently, we simply compare the performance of an experiment at one git commit to one at another commit. Though, that's not always the most interesting thing. In this project, we will explore how we can allow users to have project-specific comparisons, for instance to visualize the scalability of a parallel algorithm, or whether the microservice performs well under high load.
  • Tools for Visual Teaching and Visual Learning (HTML, CSS, JavaScript, TypeScript)
    Interactive visualizations to help lecturers to teach content in a more engaging way and to help students to learn easier. For examples, have a look at finished theses supervised by me in the past. I do not have a predefined list of visualizations that need to be implemented, but I am open to student suggestions whether they have ideas on how their own study experience could have been improved if interactive visualizations existed in their classes. Feel free to contact me if you have an idea for such a thesis.
    Contact: Dr. Markus Weninger
  • Hunting for Python Concurrency Bugs (Python, Concurrency, Threading, Parallelism)
    With Python 3.14, Python's approach to parallel execution became officially part of the language. What Python calls free threading, allows the use of multiple threads to execute Python code in parallel. This is a major shift for how Python works, and there are concerns that much of the existing Python code is not ready for this change. In the project, we want to systematically explore existing open-source Python codebases to identify potential concurrency bugs that may arise when free threading is enabled.
  • New JavaScript Language Features - ECMAScript proposals (Java, JavaScript)
    JavaScript is specified in the ECMAScript language specification. It is an evolving language, and is extended by a "proposal" process. Each new or improved feature is specified by one proposal. Current open proposals include Realms, Pipeline operator, In-Place Resizable and Growable ArrayBuffers, Array find-from-last, Array grouping, and several more. As the different proposals vastly differ in effort to implement them, we have topics for projects (project in software engineering), bachelor theses and master theses. The task is to fully implement the current state of the proposal in the GraalVM/Graal.js JavaScript engine.
    Contact: Fabio Niephaus (Oracle Labs)
  • Are We Fast Yet? Tracking the Performance of Your Favorite Language (Benchmarking, Performance)
    The Are We Fast Yet project aims to enable compiler developers and language implementers to optimize the core elements of their languages. The main idea is that a strict set of rules allows us to implement the same 14 benchmarks in different languages and then compare their performance. This allows us then to find opportunities for optimizations in the language implementations.
    This project can take many forms depending on your interests. You could port the benchmarks to new languages. This will take coming up with language-specific rules and implementing the benchmarks. Interesting languages would include, e.g., C#, Rust, PHP, Go, Scala, Kotlin, Swift, and anything else still missing from our list. Alternatively, we do not yet have a setup to automatically run the benchmarks on new versions of language implementations automatically. Ideally, we would like to be able to track performance over time. With ReBenchDB and the ReBench tool, we already have a solid foundation as well as the setup to track the data. However, the execution is not yet fully automated, and ReBenchDB could use a few more features to make such use cases easier, too.
  • A Grammar for Benchmark and Performance Analysis (Python, Benchmarking, Performance)
    A Grammar of Graphics is an approach to concisely allow data analysts to describe plots and figures and create print-quality data visualizations. ggplot2 might be the library that is most widely used by statisticians, data analysts, journalists, and researchers, with it's Layered Grammars of Graphics.
    When analyzing the performance of computer systems, we often do the same types of experiments, have the same kinds of data, and ask questions that are somewhat similar to each others. However, so far, there is no library that neatly encapsulates this insight. The goal of this project is therefore to design a library in the style of Grammar of Graphics specifically for analyzing performance data with Python and matplotlib.
  • MicroJava? Why not MicroPython, MicroC, MicroScheme, MicroGo, etc? A Family of Grammars for Compiler Construction (Compilers, Interpreters, Parsing)
    MicroJava as you know it from Compiler Construction is just one of the languages students may be interested in. The goal of this project is to develop a family of grammars for use in the compiler construction course that allow us to switch up the language year over year and offer the opportunity to build different languages over time.
  • The Simple Object Machine (Compilers, Interpreters, Performance, Benchmarking, C++, Java, JavaScript, Python)
    In Compiler Construction, we learned how to implement a minimal Java-like language. However, it lacked very many features modern languages have. The Simple Object Machine (SOM) is a different style of teaching and research language that aims to be a somewhat complete object-oriented, dynamically typed language, that has the same implementation challenges as other modern languages such as Python, JavaScript, and Ruby, but is still manageable to learn.
    A project on SOM could look into different aspects based on your interests. Here a few general ideas that can be refined to be a suitable project:
    • SOM in your Language of Choice: One could implement SOM from scratch in a language such as Zig, Swift, Ruby, OCaml, or any other language we do not already have an implementation for.
    • The fastest Interpreter: Interpreters are an important area of research since their performance determines the perceived performance for a wide range of languages. SOM++, the C++-based implementation of SOM has currently the fastest interpreter, but the results of colleagues indicate we can be 4-5x better. There are a number of optimizations that C++ could use to reach this goal.
    • MicroSOM: MicroJava has the right size to fit into a single course on compilers. What would a MicroSOM look like if we would want to teach interpreters instead of compilers? The goal here would be to reduce the feature set and investigate how to build up SOM step by step to enable a modern and captivating course on language implementation.
    • A New Interpreter: Currently, SOM++ uses a classic stack-based bytecode interpreter. Would SOM++ be faster if it would use a register-based bytecode, or an abstract-syntax-tree-based interpreter?
    • Is there some language implementation technique you are interested in? Let's define a project together!
    • SOM++ASM: Compilers are usually better than we humans when it comes to writing efficient machine code. Though, for interpreters they struggle. The goal of this project is to see what's possible when we hand-craft the perfectly optimized interpreter loop.
    • TruffleSOM: The Truffle framework has been steadily evolving to incorporate more optimizations for interpreters. The goal of this project is to evaluate the new features of the Bytecode DSL and the Graal compiler to make TruffleSOM the fastest SOM interpreter out there.
  • A Comparative Analysis of Static Site Generators (HTML, CSS, JavaScript, TypeScript, Markdown)
    Static Site Generators (SSGs) transform raw content and templates into deployable HTML files. While the core concept is simple, the ecosystem varies wildly—from classic tools like Jekyll (Ruby) to modern, JavaScript-heavy frameworks like Gatsby. The goal of this project is to implement a reference website (e.g., a documentation site or blog) across all selected frameworks to perform a structural and performance comparison.

    The student will evaluate the frameworks based on the following criteria:
    • Developer Experience: Setup complexity, templating languages (Liquid, Go Templates, JSX), and configuration.
    • Content Management: How the SSG parses Markdown and Frontmatter metadata (e.g., accessing post dates, tags, and categories).
    • Build Performance: Measuring the time required to generate the site as the number of pages increases.
    • Output Structure Analysis: A structural comparison of the generated HTML. Does the SSG produce clean, semantic markup, or does it inject unnecessary wrapper `div`s and scripts?
    • Client-Side Footprint: analyzing the "weight" of the deployed site. Does the SSG ship a JavaScript runtime (like React) to the client, or does it output zero-JS HTML?
    • Asset Processing: Capabilities for build-time image optimization (automatic resizing/format conversion) and CSS minification.
    Possible investigation targets involve Jekyll, Hugo, Eleventy, Gatsby, Next.js, and Astro.
    Contact: Dr. Markus Weninger
  • Windows Support for GraalPy (Java, Python, C, Windows APIs)
    Python on Windows provides some additional modules to access Windows-specific APIs including the MSVCRT, the registry, and the win32 API. GraalPy currently does not offer these. These modules could be implemented in pure Python using the built-in cffi or ctypes bindings, ported from CPython as a C extension library, or implemented in Java to call into the Windows APIs via Truffle NFI. The task is to weigh the implementation strategies and choose one to implement enough features to pass the standard library tests.
    Contact: Fabio Niephaus (Oracle Labs)
  • Automatic Dynamic Optimization of Remembered Sets (HotSpot JVM, C++, Garbage Collection)
    Let the G1 collector automatically determine remembered set container options for either reduced memory usage or improved performance.
    The G1 garbage collector is the current default garbage collector in the OpenJDK Hotspot VM. It uses remembered sets to store locations of incoming references to a particular region of the heap. This data structure is basically an implementation of a sparse set of integers: the entire range of possible values is split into evenly sized areas. A top level concurrent hash table stores values in areas that are "in" the set in a so-called remembered set container. Such a container is represented, depending on the number of values to be stored in that area it covers, by different kinds of data structures, e.g. arrays, bitmaps, or even single special integers.
    The remembered set implementation switches between containers on the fly depending on current remembered set entry occupancy of an area.
    G1 currently sizes these containers statically, i.e. independent of actual distribution of values in a given remembered set. So a particular container has a fixed size being able to hold a fixed amount of values, eg. an "array" remembered set container always has 128 entries, regardless of what the typical occupancy of such an array container is. This wastes memory, because different types of applications (and remembered sets for different areas of the heap) exhibit different occupancy characteristics.
    The task is to change G1 to let it reconfigure the remembered set containers based on statistics that need to be gathered while an application is running to optimize for the particular goal, and evaluate the effectiveness of these optimizations on several benchmarks.
    Contact: DI Thomas Schatzl (Oracle Java)
  • Memory Aware Liveness Analysis for G1 (HotSpot JVM, C++, Garbage Collection)
    Implement a marking algorithm that attempts to be more memory aware.
    The G1 garbage collector is the current default garbage collector in the OpenJDK Hotspot VM. Its algorithm to determine reachable objects is a straightforward implementation of the Tri-Color abstraction. One drawback of this algorithm is that memory access is very random, which is not optimal for current microarchitectures with regards to to memory accesses.
    There is an old algorithm that tends to linearize memory accesses for large object graphs, potentially reducing the amount of random memory accesses, and so improving performance. Recently, a similar approach has been implemented in Go's Green Tea garbage collector with interesting, but maybe mixed, results.
    The task for this work comprises:
    - Implement a more memory access conscious algorithm (based on these precedents) in the G1 garbage collector
    - Compare its performance, memory access behavior and memory consumption to the existing algorithm on benchmarks.
    Contact: DI Thomas Schatzl (Oracle Java)
  • Designing a music-based programming language (Compilers, Music)
    Contact: DI Christoph Pichler
    While most programming languages are text-based (i.e. the source code is written in textual form), some so-called esoteric programming languages [1] use different representations such as images [2] or theatre plays [3]. This offers the possibility to "hide" programs in media.
    The goal of this master thesis is to develop a programming language based on music: Programs of that language are not represented as text, but represent some kind of music (e.g. audio stored in the MIDI file format [4]) and can thus be listened to as well. Writing programs could be possible e.g. in a piano roll editor [5] or any notation software (e.g. MuseScore [6]). Valid programs should be "nice to listen to".
    Besides basic knowledge in compiler construction, this thesis therefore also requires background in music theory − "chords" and "harmonies" should be familiar terms.
    The tasks are (a) to design a simple programming language which is based on music/audio information, and (b) to implement a simple (e.g. stack-based) interpreter for such a language.
    Contact: DI Christoph Pichler
  • Using Fuzzing to Improve Correctness of the MicroJava Compiler as well as
    Using Model Checking to Improve Correctness of the MicroJava Compiler
    Contact: DI Christoph Pichler
    Besides testing, further techniques are common to check for correctness of programs:
    • Fuzzing is automated software testing technique that involves providing random or unexpected inputs to a program. The goal is to identify vulnerabilities, crashes, or other faults. It helps uncover security issues that may not be detected through traditional testing methods.
    • Model Checking is used to prove whether an implementation meets a given specification.
    In both cases, the proposed technique shall be used to check the implementation of a MicroJava compiler and interpreter.