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)

  • A Generic Machine Code Instrumentation Library
    Code Instrumentation is a common approach to review and analyze the performance of code and is therefore crucial to building efficient applications. The goal of this project is to develop a code instrumentation library that instruments arbitrary native code and ideally supports multiple platforms. The two major subgoals are:
    - to implement a code hooking library, that enables providing context (stack pointer, register values)
    - to provide a machine code interpreter for installing hooks. This should allow users to search for machine code patterns flexibly (by allowing some variations in the machine code) and to relocate arbitrary machine instructions.
    This master's thesis will be done in cooperation with Dynatrace who offer a part-time employment while working on the thesis.
    Contact: Prof. Mössenböck + partners from Dynatrace

  • 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: Dr. Lukas Stadler (Oracle Labs)

  • Humongous Object Aware Region Allocation (C++)
    Summary: Explore options to improve G1 humongous object inner and outer 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, for example:
    • 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).
    • region level fragmentation due to never moving these objects can cause unexpected Out-of-memory situations if there are not enough contiguous regions left for a given new allocation (outer fragmentation).

    The goal of this project would be to lessen the problem by implementing one or more changes to the existing strategy heap management. Examples are better region selection for evacuation and placement of regions, automatic region level defragmentation efforts by moving humongous objects, over-provisioning the heap area, more aggressive reclaimation of humongous objects and regular object allocation after 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 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)