From 101b5e4fd50940889057c33ed16950bebbcf686a Mon Sep 17 00:00:00 2001 From: MedSim9906 Date: Wed, 27 May 2026 10:18:34 +0200 Subject: [PATCH] Update WebAssembly Master-Thesis positions --- .../2026-02-27-dynamic-linking-in-wasm.md | 30 --------------- ...27-rust-based-in-place-wasm-interpreter.md | 38 +++++++++++++++++++ 2 files changed, 38 insertions(+), 30 deletions(-) delete mode 100644 open-positions/_posts/2026-02-27-dynamic-linking-in-wasm.md create mode 100644 open-positions/_posts/2026-05-27-rust-based-in-place-wasm-interpreter.md diff --git a/open-positions/_posts/2026-02-27-dynamic-linking-in-wasm.md b/open-positions/_posts/2026-02-27-dynamic-linking-in-wasm.md deleted file mode 100644 index dc5c1df..0000000 --- a/open-positions/_posts/2026-02-27-dynamic-linking-in-wasm.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: job -title: Evaluation and Implementation of On-Demand Module Loading in WebAssembly on Embedded Systems -tag: master -contact: simon.mederer@hm.edu ---- - -For our research group we are looking for a motivated student to evaluate and implement dynamic -linking mechanisms for WebAssembly interpreters on microcontrollers. - -WebAssembly is a modern, low-level, assembly-like language with a compact binary format designed -for improved application performance in web browsers. Through its security features like sandboxing, -it is a promising technology for a wide variety of applications. But it can also be used outside -the browser. For example, on microcontrollers. In our labs in Munich and Bad Tölz, we are currently -working on an ecosystem of efficient, practical WebAssembly runtimes and supporting tools for modern -embedded systems. - -Memory of embedded systems is always a critical limiting factor. One attempt to solve this problem -could be minimizing the code flashed onto the controller by offloading not needed code onto a server -and dynamically loading it during runtime. By being able to dynamically load and delete modules -from the controller it might be possible to execute more complex programs using less flash memory. - -The research direction is open, but the following points outline possible focus areas: -- Investigate the current state of the art of dynamic linking in terms of WebAssembly -- Evaluate linking strategies for libraries -- Implement a demonstrator that shows how dynamic linking can work in WebAssembly -- Analyze the memory savings and introduced execution overhead - -If this topic sounds interesting to you, or if you’ve been inspired and have a suggestion for a -related topic, feel free to reach out! diff --git a/open-positions/_posts/2026-05-27-rust-based-in-place-wasm-interpreter.md b/open-positions/_posts/2026-05-27-rust-based-in-place-wasm-interpreter.md new file mode 100644 index 0000000..b6b1f14 --- /dev/null +++ b/open-positions/_posts/2026-05-27-rust-based-in-place-wasm-interpreter.md @@ -0,0 +1,38 @@ +--- +layout: job +title: Feature Extension of an In-Place WebAssembly interpreter in Rust +tag: master +contact: simon.mederer@hm.edu +--- + +For our research group we are looking for a motivated student to extend our Rust-based In-Place +WebAssembly interpreter. + +WebAssembly is a modern, low-level, assembly-like language with a compact binary format designed +for improved application performance in web browsers. Through its security features like sandboxing, +it is a promising technology for a wide variety of applications. But it can also be used outside +the browser. For example, on microcontrollers. In our labs in Munich and Bad Tölz, we are currently +working on an ecosystem of efficient, practical WebAssembly runtimes and supporting tools for modern +embedded systems. Currently, we are focusing on developing a Rust-based WebAssembly In-Place +interpreter for embedded systems. + +In the context of WebAssembly, so-called rewriting interpreters are commonly used. These +interpreters transform the original bytecode into an intermediate representation (IR), which +simplifies the handling of the structured control flow of WebAssembly. In contrast, In-Place +interpreters execute the original, unmodified bytecode directly, which reduces memory overhead and +improves startup performance. Moreover, alternative execution tiers are often unsuitable for +safety-critical environments. + +The research direction is open, but the following points outline possible focus areas: +- Evaluate relevant WebAssembly proposals (e.g., Tail Calls, Threads, Component Model, ...) and + integrate them directly into the interpreter. +- Benchmark, profile, and optimize the interpreter to minimize execution latency and memory + overhead using Rust’s zero-cost abstractions. +- Investigate the usability of the Rust-based In-Place interpreter from an application-level + perspective. +- Establish a CI pipeline to automate benchmarking and profiling on target microcontroller hardware. +- Research into how WebAssembly binaries can be debugged on embedded hardware while being executed + by an In-Place interpreter. + +If this topic sounds interesting to you, or if you’ve been inspired and have a suggestion for a +related topic, feel free to reach out!