Reorder chapters + put abstract into frontmatter

chapters/05_experiment_setup/05_00_experiment_setup.tex

@@ -6,4 +6,6 @@
 
 \chapter{Experiment Setup}\label{ch:experimentsetup}
 
+\todo[inline]{Maybe split this chapter into two: Experiment Setup and Implementation}
+
 \end{document}

chapters/05_experiment_setup/05_01_execution_environment.tex

@@ -15,7 +15,7 @@ Instead, experiments are cross-compiled to freestanding executables using \code{
 To make Newlib work inside a bare-metal environment, certain system calls must be provided by the platform, although not all of them need to be functional\footnote{\url[2026-08-12]{https://sourceware.org/newlib/libgloss.html\#Libraries-1}}:
 \begin{itemize}
   \item \code{sbrk()} is required for Newlib's \code{malloc()}, \code{calloc()} and \code{realloc()} memory-management functions. Although \Gls{wamr} uses its own memory allocator implementation (see \autoref{sssec:wamrmemoryallocation}), \Gls{wasm} targets may still require a functional \code{sbrk()} if \Gls{wamr}'s \code{snprintf}/\code{vsnprintf} are used, depending on the format string.
-  \item \code{read()}, \code{write()}, \code{close()}, \code{fstat()} and \code{isatty()} stubs are required for \Gls{wamr} targets. Since no filesystem or console exists in the execution environment, they do not need to implement functional behavior.
+  \item \code{read()}, \code{write()}, \code{close()}, \code{fstat()} and \code{isatty()} stubs are required for \Gls{wamr} targets. Since no filesystem or console exists in the execution environment, the stubs do not need to implement functional behavior.
   \item \code{lseek()} is required for C and \Gls{wamr} targets. A stub suffices for the same reason as above.
   \item \code{\_exit()}, \code{kill()} and \code{getpid()} are required for \Gls{wamr} targets. Implementations can be omitted, as the execution environment does not use processes.
 \end{itemize}

chapters/05_experiment_setup/05_03_workload_structure.tex

@@ -9,7 +9,7 @@
 \subsection{Shared Traced Region}\label{ssec:sharedtracedregion}
 
 All experiment variants (C, \Gls{aot} and interpreted) share the same traced region on the source level that contains the actual benchmarked workload.
-It is structured into three parts, the benchmark initialization, its execution and the success condition.
+It is structured into three parts: the benchmark initialization, its execution and the success condition.
 Initialization and success condition lie outside the traced region (see \autoref{lst:workloadstructure}), so a workload under fault always starts with its intended initial state and its result evaluation is trustworthy.
 
 \begin{codeblock}[label=lst:workloadstructure]{Example of a shared workload.}{C++}
@@ -33,7 +33,7 @@ The \code{MAIN} and \code{RET} macros expand according to the appropriate entry
 
 \subsection{Wasm Host and WAMR Setup}\label{ssec:wasmhostandwamrsetup}
 
-The host program for \Gls{wasm} experiment variants needs to do a lot of additional work compared to the native one, mainly concerning the initialization of the \Gls{wamr} runtime\footnote{Described here: \url[2026-09-11]{https://wasmruntime.com/en/tutorials/wamr\#34-step-4-c-embedding-integration}}.
+The host program for \Gls{wasm} experiment variants needs to do additional work compared to the native one, mainly concerning the initialization of the \Gls{wamr} runtime\footnote{Described here: \url[2026-09-11]{https://wasmruntime.com/en/tutorials/wamr\#34-step-4-c-embedding-integration}}.
 
 \subsubsection{Runtime Initialization and Memory Allocation}\label{sssec:wamrmemoryallocation}
 
@@ -42,7 +42,7 @@ Relevant for this thesis are \code{Alloc\_With\_Pool} and \code{Alloc\_With\_All
 \code{Alloc\_With\_Pool} is the simplest one, as it only requires a memory pool, no custom allocator functions.
 \code{Alloc\_With\_Allocator} is slightly more involved, as it allows complete control over memory regions and allocation behavior by utilizing custom allocator functions.
 To use this allocator, \code{malloc}, \code{realloc} and \code{free} need to be implemented.
-In this thesis, a simple bump allocator is implemented, like the one used by \Gls{wamr} itself, described in \autoref{ssec:wamrbaremetal}
+In this thesis, a simple bump allocator is implemented, like the one used by \Gls{wamr} itself, described in \autoref{ssec:wamrbaremetal}.
 
 \begin{codeblock}[label=lst:wamrinit]{\Gls{wamr} initialization.}{C++}
   \inputminted{cpp}{listings/wamrinitialization.cpp}
@@ -74,7 +74,7 @@ This indirection happens implicitly, on the application level no special steps n
 To be compatible with the native function registration mechanism, functions need to accept the \Gls{wasm} execution environment as an argument (see \autoref{lst:wamrnativefunctions}).
 
 It is important to consider that this native call mechanism introduces additional overhead that provides additional attack surface during fault-injection.
-The return from the \code{fail\_start\_trace} call, the entry into the \code{fail\_stop\_trace} call and the entireties of any other marker calls within the traced region are susceptible to faults unintended in the experiment design: the source code instrumentation should only steer the fault-injection process, not interact with the workload execution itself.
+The return from the \code{fail\_start\_trace} call, the entry into the \code{fail\_stop\_trace} call and the entirety of any other marker call within the traced region are susceptible to faults unintended by the experiment design: the source code instrumentation should only steer the fault-injection process, not interact with the workload execution itself.
 How to counteract this limitation is described later, in \autoref{sec:resultfiltering} and \autoref{sec:resultextractionandqueries}.
 
 \subsubsection{Wasm Module Instantiation and Execution}\label{sssec:wamrmoduleexecution}