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)


  • New WebAssembly Language Feature - Exception Handling Proposal (Java, some WebAssembly)
    WebAssembly is specified in the WebAssembly specification and evolves through "proposals" that define new language features. One of these new proposals is the Exception Handling Proposal, which introduces support for exceptions into WebAssembly. The task is to fully implement the current state of this proposal in the GraalWasm WebAssembly engine. This includes updates to the parser, internal bytecode, the WebAssembly bytecode interpreter inside GraalWASM, and additional tests. As this proposal has a limited scope, it is a good fit for a bachelor thesis or project in software engineering.

  • Program optimization based on concolic execution (Java)
    Concolic testing uses a mixture between symbolic and concrete execution to generate new test input with the goal of increasing test coverage. In this project a similar idea should be explored: Execute a program with user-supplied inputs and keep track of computation results (branches taken, computed values, variable assignments). Then identify optimization potentials from the gathered information and report it to the user. The goal is to implement a tool in Java that performs this task.

  • Tools for Visual Teaching and Visual Learning (e.g., HTML + CSS + Typescript)
    Interactive visualizations to help lecturers to teach content in a more engaging way and to help students to learn easier.

  • New JavaScript Language Features - ECMAScript proposals (Java, some 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)

  • 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)

  • Allocate Objects into Tail End of Humongous Regions (C++)
    Summary: Improve memory footprint of G1 humongous objects by removing inner fragmentation.
    The G1 garbage collector is high-performance regional collector in the OpenJDK Hotspot VM: the Java heap is strictly split into same-sized regions. Objects larger than a single region ("humongous regions") are allocated using separate contiguous sets of regions, and are mostly unmovable for performance reasons.
    This poses a few problems, in particular at the end of such a humongous region there is often a significant amount of space that is effectively wasted and unavailable for allocation (inner fragmentation, explanation, enhancement request). The goal of this project would be to lessen the problem by implementing regular object allocation into the tail region of a humongous object.
    Contact: DI Thomas Schatzl (Oracle Java)

  • Automatic Dynamic Optimization of Remembered Sets (C++)
    Summary: 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)

  • Fixed Memory Usage Marking for G1 (C++)
    Summary: Implement a marking algorithm that uses (small) constant memory and compare with the existing.
    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. The drawback of this algorithm is that mark stack, a helper data structure, memory requirements is only bounded by the number of live objects which can be a very large number (in the MBs).
    There is an algorithm that bounds only needs a very small mark stack and a small helper table to complete marking.
    The task for this work comprises:
    - Implement the mentioned algorithm in the G1 garbage collector
    - The description only describes single-threaded operation, extend it to use multiple threads.
    - Compare its performance and memory consumption to the existing algorithm on benchmarks.
    Contact: DI Thomas Schatzl (Oracle Java)