Statistical Program Slicing

• Statistical program slicing is a family of techniques that use runtime sampling, learned inference, or quantitative semantics to approximate program slicing for debugging and analysis.
• It balances dynamic precision with static efficiency by sampling execution traces and employing language models to predict code dependencies.
• The approach offers practical benefits in debugging, code comprehension, and probabilistic verification while trading off absolute soundness for improved performance.

Statistical program slicing denotes a family of slicing approaches in which the relation between a slicing criterion and the retained program statements is established through sampled runtime evidence, learned inference, or quantitative probabilistic semantics rather than only through conventional dependence-graph reachability. In current research usage, the expression covers several distinct strands. This suggests that the term is polysemous rather than standardized: it names an explicit hybrid dynamic-static debugging technique in deployed software, it is also used in a broader sense for learning-based static slicers driven by LLMs, and it is closely related to semantic slicing for probabilistic programs whose correctness is stated over distributions, expectations, or verification judgments (Stoica et al., 2021, He et al., 9 Apr 2026, Amtoft et al., 2017).

1. Terminological scope and boundaries

The literature does not use a single canonical definition of statistical program slicing. One line of work uses the phrase literally as the title of a hybrid slicing technique for deployed software. A second line treats the phrase more broadly as shorthand for learning-based static slicing, where pretrained models replace explicit symbolic dependence construction. A third line concerns slicing of probabilistic programs, where the preserved object is not a concrete variable value but a quantitative property such as a marginal distribution, an expectation bound, or a verification condition.

Usage	Preserved object	Representative papers
Hybrid dynamic-static slicing	Approximation of a dynamic slice for a failing execution	(Stoica et al., 2021)
Learning-based static slicing	Predicted static backward slice	(Chang et al., 25 Jul 2025, He et al., 9 Apr 2026, He et al., 22 Sep 2025)
Probabilistic-program slicing	Quantitative semantics or verification property	(Amtoft et al., 2017, Navarro et al., 2022, Schröer et al., 23 Dec 2025)

Adjacent areas are often confused with statistical program slicing but are technically distinct. The fault-localization study comparing statistical debugging with dynamic slicing explicitly treats the two as complementary paradigms rather than as variants of the same method, and recommends a hybrid workflow that inspects a few statistically suspicious locations before switching to slicing (Soremekun et al., 2021). Likewise, some papers use slicing inside larger AI or static-analysis pipelines while stating that the slicing itself is not statistical, such as the DG-based slicing phase in SLD-Spec and the KDM-based backward slicing for JEE output streams (Chen et al., 12 Sep 2025, Shatnawi et al., 2018).

2. Hybrid dynamic-static statistical slicing

In the narrowest and most explicit sense, statistical program slicing is the hybrid technique introduced for debugging deployed software in "Statistical Program Slicing: a Hybrid Slicing Technique for Analyzing Deployed Software" (Stoica et al., 2021). Its motivation is the tension between exact dynamic slicing, which is highly informative for a specific failure but too expensive for production deployment, and static slicing, which is cheaper but substantially less precise. The method therefore explores the trade-off between slice accuracy and runtime cost by reconstructing an approximation of the dynamic slice from low-overhead runtime observations and offline static analysis.

The implementation, Wok, combines Intel Processor Trace for precise control-flow tracing, a cooperative heap memory tracing mechanism based on pointer poisoning and sampling, and execution-driven static alias analysis. Runtime monitoring records exact control flow for the failing execution and sampled heap access information across many executions. Offline analysis then aggregates these observations into an observed dependency graph, supplements missing memory dependences with interprocedural flow-insensitive Andersen-style must-alias analysis restricted to executed code, and performs a backward traversal from the seed instruction. The resulting slice is therefore neither a textbook static slice nor an exact dynamic slice, but a projection of the dynamic slice onto static code, pruned by the failing execution’s control flow and reconstructed from sampled cross-run evidence.

The quantitative results are the defining empirical claim of this strand. Wok recovers 94% of the program statements on a dynamic slice with only 5% runtime overhead, recovers 89% of the data dependencies located on precise dynamic slices, recovers 92% of the statements linking the symptom to the root cause, yields statistical slices that are on average 89% larger than exact dynamic slices, and produces failure paths that are only 21% larger on average (Stoica et al., 2021). To remain within a $\le 5\%$ overhead budget, the implementation chooses a sampling rate between $\frac{1}{10{,}000}$ and $\frac{1}{100{,}000}$, poisoning roughly 1 in 10,000 to 1 in 100,000 allocated pointers. The paper is explicit that the approach is unsound by design: the observed dependency graph is an approximation assembled from partial evidence, so missed dependences can omit relevant statements and cross-run aggregation can introduce extra statements. The statistical aspect is therefore operational rather than Bayesian: sampling and aggregation replace exhaustive tracing.

3. Learning-based and LLM-assisted static slicing

A broader contemporary usage treats statistical program slicing as static slicing performed by learned models rather than exact dependence reachability. This usage is interpretive rather than terminologically uniform. SliceMate explicitly states that it does not present an explicit probabilistic model, a Bayesian slicer, or a supervised model trained end-to-end on slicing labels; instead, it uses LLM inference to replace much of the explicit symbolic dependency-graph construction and reachability analysis of traditional static slicing (Chang et al., 25 Jul 2025). SliceMate’s synthesis, verification, and refinement agents operate over a criterion given by file path, line number, and criterion statement or variables, and the system evaluates slices in terms of completeness and conciseness on SliceBench, a benchmark of 2,200 manually annotated Java and Python programs. This suggests a modern broad sense in which statisticality resides in pretrained neural inference rather than in a formal statistical estimator.

Sliceformer is the clearest example of a learning-based statistical slicer in the narrow technical sense. It reformulates static backward slicing as a seq2seq task whose input is $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$ and whose output is an ordered subsequence of statements from the original code up to the criterion line (He et al., 9 Apr 2026). Rather than computing a slice from a PDG or SDG at inference time, it trains a small LLM to predict slices from examples, while using data flow graphs only to shape pretraining. Its two main devices are dataflow-aware pretraining and constrained decoding. On the Java benchmark it reports Acc-D $98.78$, ExactMatch $92.20$, CodeBLEU $93.23$, and TSED $97.68$; on Python it reports Acc-D $90.85$, ExactMatch $83.15$, CodeBLEU $\frac{1}{10{,}000}$0, and TSED $\frac{1}{10{,}000}$1, with up to 22% gain in ExactMatch over state-of-the-art baselines (He et al., 9 Apr 2026).

SliceT5 occupies the same design space but strengthens extractive fidelity through a copy mechanism and constrained decoding (He et al., 22 Sep 2025). It also formulates slicing as seq2seq generation from a code snippet plus a variable-and-line-number criterion, but mixes vocabulary generation with copying by

$\frac{1}{10{,}000}$2

Inference is constrained both lexically, by restricting outputs to input tokens, and syntactically, by pruning beams when TSED monotonicity is violated. The paper reports ExactMatch $\frac{1}{10{,}000}$3 on CodeNet and $\frac{1}{10{,}000}$4 on LeetCode, with up to 27% relative improvement in ExactMatch, and emphasizes robustness to incomplete code such as missing class encapsulation, missing semicolons, and missing or unmatched braces (He et al., 22 Sep 2025). Across these papers, the key commonality is that slice membership is predicted from learned regularities in code and criterion context, not derived exactly from a compiler-grade symbolic representation.

4. Probabilistic-program slicing

A different but closely related branch studies slicing for probabilistic programs. Here the central issue is not sampled runtime evidence or learned prediction, but semantic preservation of a quantitative object. "A Theory of Slicing for Probabilistic Control-Flow Graphs" develops slicing over pCFGs whose nodes modify subprobability distributions and shows that classical machinery such as data dependence, control dependence, postdominators, and relevant variables can be lifted to the probabilistic setting only if one adds a new ingredient: probabilistic independence between two disjoint slices (Amtoft et al., 2017). The slice specification therefore uses a pair $\frac{1}{10{,}000}$5 of disjoint weak slices. $\frac{1}{10{,}000}$6 is the retained slice; $\frac{1}{10{,}000}$7 contains removed observe nodes and the nodes on which they depend. The main semantic guarantee states that, under an independence condition on relevant variables, there exists $\frac{1}{10{,}000}$8 such that the original and sliced programs agree on the marginal over relevant variables up to the multiplicative factor $\frac{1}{10{,}000}$9. The paper also gives an $\frac{1}{100{,}000}$0 algorithm for the least slice and shows that knowledge of almost-sure termination can justify smaller slices.

Specification-based slicing for probabilistic programs strengthens this semantic view by making the specification itself the slicing criterion. "Slicing of Probabilistic Programs based on Specifications" defines a slice $\frac{1}{100{,}000}$1 to be correct when validity of the original annotated probabilistic program with respect to a pre/post pair $\frac{1}{100{,}000}$2 implies validity of the slice with respect to the same specification (Navarro et al., 2022). The method propagates post-expectations backward via $\frac{1}{100{,}000}$3, $\frac{1}{100{,}000}$4, and verification-oriented transformers such as $\frac{1}{100{,}000}$5, and it is explicitly termination-sensitive. The paper states

$\frac{1}{100{,}000}$6

Its claim is that specification-preserving slices can be strictly more precise than conventional data/control-dependence slices because code may affect variables syntactically without contributing to the required lower bound on the post-expectation.

Verification-driven slicing for probabilistic programs pushes the criterion from program behavior to proof behavior. "Error Localization, Certificates, and Hints for Probabilistic Program Verification via Slicing" introduces error-witnessing slices, verification-witnessing slices, and verification-preserving slices over HeyVL and implements them in Caesar under the name Brutus (Schröer et al., 23 Dec 2025). The preserved object is no longer a variable value or even a marginal distribution, but whether a quantitative triple verifies or fails. The paper defines, for example, an error-witnessing slice $\frac{1}{100{,}000}$7 by requiring both $\frac{1}{100{,}000}$8 and transfer of every counterexample state of $\frac{1}{100{,}000}$9 to the original program. Algorithmically, Brutus searches over transformed verification conditions using binary search, unsatisfiable cores, minimal unsatisfiable subset enumeration, and direct $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$0 SMT encodings.

The correctness proofs for such probabilistic slicing transformations involve fixed-point subtleties that do not occur in ordinary lockstep iteration from bottom. "A Fixed Point Iteration Technique for Proving Correctness of Slicing for Probabilistic Programs" abstracts the required proof pattern: source and target semantics are each least fixed points, but the proof must iterate from a non-bottom seed on an exclusion set $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$1, because source and target approximants can accumulate probability mass at different rates (Amtoft et al., 2024). This methodological result does not introduce a new slicing notion, but it clarifies why probabilistic slicing correctness often requires more than standard fixed-point induction.

5. Algorithms and formal criteria

Despite the terminological variation, several algorithmic patterns recur across the field. Classical static slicing remains the reference point. The JEE-oriented output-stream slicer builds a dependence graph over KDM ActionElement instances, reverses the edges to obtain a transpose graph, and then runs Breadth-First Search from a print, write, or append call to compute a backward slice of statements that may affect the value written to the output stream (Shatnawi et al., 2018). The graph is built intraprocedurally over statements in a given method, with control and data dependence only, and the transpose is defined by

$\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$2

This is not statistical slicing, but it provides the baseline symbolic pattern against which later learned systems are defined.

Hybrid statistical slicing reuses the same backward-reachability intuition, but on an observed dependency graph assembled from partial evidence rather than on a fully constructed PDG or DDG (Stoica et al., 2021). Learning-based slicers replace graph construction altogether with extractive transduction. Sliceformer encodes the input criterion as a variable $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$3 and a line number $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$4, predicts an ordered subsequence of source statements, and constrains generation with lexical masking and a TSED-based structural filter (He et al., 9 Apr 2026). SliceT5 adds a copy mechanism so that source-grounded extraction is not merely encouraged but built directly into the decoding distribution (He et al., 22 Sep 2025). SliceMate abandons graph construction more radically by using agentic LLM reasoning to expand scope across functions and files, verify completeness and conciseness, and iteratively refine the slice until convergence or a threshold of five iterations is reached (Chang et al., 25 Jul 2025).

This diversity of algorithms supports a broad encyclopedic conclusion. Statistical program slicing is not associated with one formal criterion comparable to Weiser’s original $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$5 notation. Instead, the criterion depends on the strand: a seed instruction in a failing execution for Wok, a variable-line pair for learning-based static slicing, a retained set of relevant variables in a pCFG, or a quantitative verification judgment in HeyVL. This suggests that the unifying theme is not syntax but the replacement or extension of exact symbolic reachability by sampled evidence, learned inference, or semantic proof obligations.

6. Applications, empirical behavior, and recurring limitations

Program slicing remains valuable for debugging, testing, optimization, maintenance, security, and code understanding, and statistical variants inherit those application domains while changing the cost-precision trade-off (Stoica et al., 2021). The deployed-debugging setting is the clearest example: Wok is designed for failures whose inducing inputs are hard to recover and for environments where always-on instrumentation must stay near production overhead (Stoica et al., 2021). Learning-based static slicers emphasize debugging and security auditing, especially when code is large, incomplete, or unparsable (Chang et al., 25 Jul 2025, He et al., 22 Sep 2025). JEE-specific slicing targets response-generation logic and is explicitly motivated by software comprehension, maintenance, evolution, change impact analysis, and debugging of server-side output construction (Shatnawi et al., 2018).

The empirical picture is heterogeneous. Hybrid deployed slicing demonstrates strong recovery with low runtime cost but is unsound by design and depends on cross-run coverage of relevant heap dependences (Stoica et al., 2021). Learning-based slicers achieve high ExactMatch on benchmarked Java and Python tasks, yet their outputs are empirically good rather than formally certified. SliceMate states that there is no formal soundness or completeness guarantee, despite its strong benchmark results and low reported cost of $\bm{x} = \{s_1, s_2, \dots, s_N; v; [n]\}$6 US dollars per slice on large-scale programs (Chang et al., 25 Jul 2025). Sliceformer and SliceT5 mitigate hallucination and overgeneration through constrained decoding, but they still predict slices rather than compute them exactly, and out-of-domain performance remains markedly lower than in-domain performance, particularly on LeetCode for SliceT5 (He et al., 9 Apr 2026, He et al., 22 Sep 2025).

A recurring misconception concerns the relation between statistical program slicing and statistical fault localization. The large empirical comparison between dynamic slicing and SBFL treats them as distinct methods: statistical debugging ranks statements by coverage-failure correlation, whereas slicing follows backward dependencies from the symptom (Soremekun et al., 2021). For single faults, dynamic slicing is reported as eight percentage points more effective than the best SBFL formula on average; for multiple faults, statistical debugging performs better; and the best overall results come from a hybrid that inspects at most the top five suspicious SBFL statements and then switches to slicing, requiring examination of about 15% of the code, or 30 lines on average (Soremekun et al., 2021). The paper’s framing is explicit: slicing is not statistical debugging, even when the two are profitably combined.

Taken together, these strands show that statistical program slicing is best understood as a family of non-uniform but technically connected ideas. In one sense it is a production-oriented approximation of dynamic slicing built from sampled execution evidence. In another it is a learned approximation of static backward slicing using neural inference instead of exact dependence solving. In a third, closely related sense, it is semantic slicing for probabilistic programs, where the preserved quantity is a distributional or verification-theoretic object rather than a concrete variable value. The common feature across these senses is a shift away from purely symbolic dependence preservation toward relevance criteria expressed through observation, inference, or quantitative semantics.