Home
General
Staff
Contact
Partners
Alumni
Research
Areas
Projects
Papers
Books
Reports
Awards
Teaching
Lectures
Exams
B.Projects
M.Theses
PhD Theses
Go Abroad
Misc
Talks
Library
Gallery
Links
Search
Webmaster
|
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)
-
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.
-
CI Upgrades for LaTeX Builds in Software Development 1 (UE) (e.g., Python, TypeScript, LaTeX)
The lab (UE) for Software Development 1 is organised via a git repository.
When preparing an exercise, we use pull requests to gather feedback from colleagues and discuss the subject matter.
While we use a customized CI pipeline that automatically builds the lecture documents from TeX files, projects in this area focus on improving this process by integrating further checks and features, such as spell checking, linting, and formatting of TeX files and other auxiliary material (source code, figures), as well as other customizable checkers and feedback tools.
-
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.
-
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.
-
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.
-
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.
-
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.
|
