Marauder: Unified Mutation Management

• Marauder is a declarative framework for managing hand-crafted mutants in fuzzing and property-based testing, unifying five mutation representations.
• It introduces a mutation algebra that schedules and composes higher-order mutant combinations while preserving each mutant’s identity.
• The system employs a lossless conversion pipeline to a common intermediate form, balancing readability, mutation preservation, and execution efficiency.

Searching arXiv for the specified paper and any directly relevant related work mentioned in the provided data. Marauder is a declarative framework and prototype system for designing, managing, and executing hand-crafted mutants across multiple representations, with formal semantics for selection, expansion, and higher-order combinations, and a lossless conversion pipeline to a common intermediate form. It is situated in the evaluation of fuzzing and property-based testing (PBT) tools, where hand-crafted mutants are used because they can reflect realistic bugs, support reliable triggering and unambiguous detection, and help guard against overfitting and deduplication pitfalls. Within that setting, Marauder addresses a design space structured by three recurring tensions: readability, mutation preservation, and execution cost (Keles, 7 Mar 2026).

1. Problem setting and motivation

Marauder targets the growing use of hand-crafted mutants in fuzzing and PBT evaluation. The motivating premise is that expert-designed mutants are often preferred for realism and relevance, especially in benchmark construction. The underlying problem is not merely how to inject mutants, but how to preserve their identity, activate them selectively, compose them into higher-order products, and execute them efficiently across different implementation strategies (Keles, 7 Mar 2026).

The framework is motivated by limitations in existing tooling. Source-level mutation styles are often easy to read and present as diffs, but they may be tied to language-specific tooling or brittle patterns. Some comment-based syntaxes consume structure upon activation, which destroys mutation boundaries and impedes later analysis or composition. At the same time, approaches based on source rewriting typically require per-mutant recompilation, and this cost becomes dominant in languages with expensive compilation pipelines such as Rust, Haskell, and OCaml. Lower-level or in-AST approaches mitigate recompilation overhead but reduce readability and require language awareness (Keles, 7 Mar 2026).

This configuration of trade-offs explains Marauder’s central contribution: it formalizes the design space of hand-crafted mutation systems and provides mechanisms for moving among representations without losing mutation structure. A plausible implication is that mutation management becomes an experimental systems problem rather than merely a notation problem; representation choice can then be varied per phase of the workflow rather than fixed globally.

2. Mutation representations

Marauder characterizes five mutation representations: comment-based, preprocessor-based, patch-based, match-and-replace, and in-AST mutations (Keles, 7 Mar 2026). Each representation offers a different balance among local readability, preservation of mutation identity, and activation cost.

Representation	Expression form	Main trade-off
Comment-based	Inline blocks with base and variants	Highly readable; per-mutant recompilation
Preprocessor-based	#if / #elif / #else with flags	Preserving and language-agnostic; recompilation still required
Patch-based	Base fragment plus unified diffs and manifest	Readable diffs and preservation; positional sensitivity
Match-and-replace	Structured JSON with scope, match, and replacements	Structured and language-agnostic; matching can be brittle
In-AST	Runtime-activated branches embedded in the AST	No per-mutant recompilation; reduced source readability

Comment-based mutations encode a variation directly in source using inline blocks that contain a base and one or more variants. Their main advantage is readability: they preserve near-source context and are straightforward to parse and present. Their main disadvantages are recompilation cost and syntax collisions. Marauder’s explicit end marker |*/ is a preservation mechanism intended to prevent structural destruction after activation (Keles, 7 Mar 2026).

Preprocessor-based mutations encode alternatives under compile-time flags. This approach is mutation-preserving and language-agnostic, because toggling is externalized through build configuration rather than source rewriting. However, it still incurs recompilation and reduces source readability by scattering selection logic into conditional branches (Keles, 7 Mar 2026).

Patch-based mutations externalize variants as unified diffs coupled to a manifest that records metadata such as path and tags. This representation is readable in the specific sense that variants are visible as diffs, easy to apply and revert, and preserved in the patch store. Its weaknesses are positional sensitivity and the need for auxiliary metadata to reconstruct grouping and tags (Keles, 7 Mar 2026).

Match-and-replace mutations store a scoped region, a base match pattern, and variant replacements in structured JSON. This is also language-agnostic and useful for simultaneous application or pipeline-oriented workflows, but its robustness depends on the stability of matching. Readability is mediated by tooling rather than by the source artifact itself (Keles, 7 Mar 2026).

In-AST mutations embed language-aware mutation branches directly into the AST and activate them at runtime, for example via a mutation_active("name") predicate. This avoids per-mutant recompilation and is therefore attractive when compilation cost dominates. The cost of that efficiency is reduced visual simplicity, language specificity, and the need to ensure that every branch remains a valid AST subtree (Keles, 7 Mar 2026).

Taken together, these representations define the operational design space that Marauder seeks to unify. The framework does not eliminate the underlying trade-offs; rather, it provides a mechanism for navigating them without loss of mutation identity.

3. Mutation algebra and execution semantics

A central component of Marauder is its mutation algebra, a declarative language for selective execution, tag-based expansion, and higher-order combinations. Its abstract syntax is given by

$$\text{expr ::= expr + expr \;|\; expr * expr \;|\; +tag \;|\; *tag \;|\; mutant \;|\; mutation}$$

where mutations are named variations, mutants are named variants belonging to exactly one mutation, and tags define a finite tagging relation over mutants (Keles, 7 Mar 2026).

The semantic target of the algebra is a schedule. A product $p \subseteq M$ is a set of simultaneously active mutants, corresponding to a higher-order combination. A schedule $S$ is a finite sequence of products $[p_1,\dots,p_n]$, corresponding to sequential runs. Atomic expressions map either to singleton products for individual mutants or to enumerations over all mutants in a mutation. Tag expansions provide two distinct operational modes: +t enumerates each tagged mutant one-by-one, whereas *t produces a single product containing all tagged mutants activated together (Keles, 7 Mar 2026).

Sequential composition is defined by list concatenation, so order matters:

$\llbracket E_1 + E_2 \rrbracket = \llbracket E_1 \rrbracket \mathbin{\unicode{x29FA}} \llbracket E_2 \rrbracket$

Parallel composition forms pairwise unions of products:

$$\llbracket E_1 * E_2 \rrbracket = [\, p_1 \cup p_2 \mid p_1 \in \llbracket E_1 \rrbracket,\; p_2 \in \llbracket E_2 \rrbracket \,]$$

Marauder imposes a mutual exclusivity constraint: a product is invalid if it contains distinct mutants from the same mutation. Such conflicts are rejected as errors. Complex expressions are normalized to sum-of-products schedules by distributing * over + via the semantic definition above (Keles, 7 Mar 2026).

The algebra is significant because it elevates mutation execution from ad hoc scripting to an explicit scheduling formalism. Inside a product, set union is commutative and associative, so activation order within a simultaneous run is irrelevant. By contrast, schedule concatenation is intentionally order-sensitive. This distinction cleanly separates higher-order mutant construction from sequential experimental design. The tag operators further make it possible to encode experimental subsets such as difficulty or size and then choose between individual evaluation and grouped activation without rewriting mutation definitions.

4. Common intermediate form and lossless conversion

Marauder maps all five representations into a common intermediate form (CIF) that interleaves code fragments and mutation blocks. For each variation, CIF records the variation name, tags, location scope, base snippet, and a list of variants consisting of mutant names and replacements (Keles, 7 Mar 2026).

The conversion pipeline is explicitly designed to be lossless. Extraction proceeds from the source representation into CIF by representation-specific parsing. Comment-based mutations are parsed via begin markers, variant headers, bodies, and end markers. Preprocessor-based mutations are reconstructed from conditional chains and flag names, with tags supplied through a manifest. Patch-based mutations are recovered from manifests and unified diff hunks, including scope reconstruction and context resolution. Match-and-replace mutations are imported directly from JSON fields. In-AST mutations are extracted by recognizing reserved runtime constructs such as a match () guarded by mutation_active("name") (Keles, 7 Mar 2026).

A key technical issue is normalization. Some source-level edits do not form standalone AST nodes, especially when they split tokens or span only a sub-expression. Marauder therefore normalizes such edits to the smallest valid syntactic unit by lifting them to the minimal enclosing node so that every variant and the base become syntactically valid. The example in the source material moves from an inline argument-level edit to a whole-call representation, thereby preserving the semantic distinction while ensuring AST-valid rendering (Keles, 7 Mar 2026).

Rendering is then the inverse map from CIF to a target representation. Comment-based output emits begin, variant, and end markers while preserving names and tags. Preprocessor rendering emits conditional blocks and a manifest linking variant names to flags. Patch-based rendering generates a base file, per-variant unified diffs, and a manifest. Match-and-replace rendering produces JSON with scope, base match, and replacements. In-AST rendering introduces mutation_active conditionals and relies on normalized CIF to guarantee branch validity (Keles, 7 Mar 2026).

This pipeline is the structural core of Marauder. It means that representation choice is not a one-way commitment. Readability-oriented curation can occur in one form, execution-oriented scaling in another, and sharing or archival in yet another, while preserving mutation identity, tags, and scope metadata.

5. Implementation and workflow

Marauder is implemented as a prototype system with parsers and renderers for the five representations, CIF as the central data structure, a mutation algebra engine that evaluates expressions into sum-of-products schedules, and activators specialized to each representation (Keles, 7 Mar 2026).

The activation mechanism depends on representation. For comment-based mutations, markers are rewritten to set or unset the active variant for a block while preserving the explicit end marker |*/. For preprocessor-based mutations, compile-time flags are managed through a manifest. For patch-based mutations, unified diffs are applied and reverted. For match-and-replace, replacements are applied within recorded scopes. For in-AST mutations, a runtime library exposes mutation_active(name) and activation is controlled by runtime state; one cold compile suffices, and resetting clears the activation set (Keles, 7 Mar 2026).

The CLI/API comprises several operations. list enumerates mutations with names, tags, and locations. set/unset <mutant_name> activates or deactivates a single mutant. reset deactivates all mutants. test "<expr>" --cmd "<command>" evaluates an algebraic expression into a schedule, activates the corresponding mutants product by product, runs the given command, and aborts on conflicts in a product. convert --to <representation> transforms the current project’s mutations to a target representation through CIF. import cargo-mutants ingests automated mutants as a starting point for later curation and conversion into hand-crafted blocks (Keles, 7 Mar 2026).

The implementation also includes IDE integration through a VS Code plugin, ETNA IDE, which can view mutations inline, activate and deactivate them, reset them, and convert them. This suggests a workflow in which authoring, curation, selective evaluation, and representation shifts can occur within a single interactive environment rather than through disconnected scripts and preprocessing stages.

6. Performance, trade-offs, and limitations

The performance evaluation on ETNA Rust workloads compares comment-based and in-AST execution for BST, RBT, and STLC mutants. The reported compilation speedups for in-AST relative to comment-based execution are 1.84× for BST, 1.82× for RBT, 1.13× for STLC, and 1.42× in total. The reported execution slowdowns are 1.30× for BST, 1.12× for RBT, 1.07× for STLC, and 1.08× in total (Keles, 7 Mar 2026).

The paper summarizes these costs with two time models:

$$T_{\text{comment}} = \text{compile}_{\text{cold}} + (n-1)\times \text{compile}_{\text{warm}} + \text{execution}$$

$$T_{\text{in-ast}} = \text{compile}_{\text{cold}} + \text{execution}$$

These models make explicit why in-AST mutation can be advantageous in high-compile-cost settings: it removes the repeated rebuild term while incurring only modest runtime overhead for mutation management (Keles, 7 Mar 2026).

The framework’s design decisions therefore correspond to distinct optimization priorities. Comment-based mutations are improved to preserve structure and avoid marker collisions, emphasizing curation and analyzability. Preprocessor, patch, and match-and-replace approaches externalize activation while preserving mutation identity and tags. In-AST prioritizes execution efficiency and composability, while accepting lower source readability. CIF and conversion are the mechanisms that allow these priorities to coexist in one system rather than competing as incompatible tool ecosystems (Keles, 7 Mar 2026).

The reported limitations are also explicit. In-AST mutation is currently implemented for Rust, and extension to other languages requires AST tooling and runtime hooks. Conversion and normalization have been tested in the prototype, but formal proofs of correctness are planned. Some fine-grained source edits cannot be represented directly as AST branches without normalization, and lifting to an enclosing node may slightly change context, although the semantics of variants are stated to remain intact. Performance results are drawn from ETNA Rust workloads, so effects may vary by language, build system, and test workload (Keles, 7 Mar 2026).

7. Position within mutation-analysis tooling

Marauder is framed relative to several strands of mutation tooling and benchmark methodology. The related-work discussion mentions source-level tools such as mutmut for Python and StrykerJS for JavaScript, bytecode-level mutation through PIT for Java, compiler or AST-level mutation through Major for Java, and IR-level or in-memory mutation through Mull for C++. It also notes recent any-language generation via syntax-driven approaches, specifically UniversalMutator and “Syntax Is All You Need.” On the evaluation side, FuzzBench, Magma, and FixReverter are cited as illustrating pitfalls in fuzz evaluation, while ETNA demonstrates hand-crafted mutants for PBT workloads (Keles, 7 Mar 2026).

Within that landscape, Marauder’s role is not to replace automated mutant generation systems or benchmark suites. Its contribution is to manage manual mutants with preservation, selection, conversion, and efficient execution strategies. This is a distinct systems layer: it concerns how hand-crafted mutants are represented, scheduled, activated, combined, and transported across execution models. A plausible implication is that Marauder is most relevant where mutant realism is already taken as a methodological requirement and the remaining challenge is to make that realism operationally tractable at scale.

In summary, Marauder defines a unified framework for hand-crafted mutation analysis and management by combining a five-representation taxonomy, a mutation algebra over schedules and higher-order products, and a lossless CIF-based conversion pipeline. Its primary significance lies in making representation choice reversible and explicit, thereby enabling mutation experiments that can be tuned for readability during curation, preservation during sharing and analysis, and execution efficiency during large-scale testing (Keles, 7 Mar 2026).