---
title: 'SliceT5: Copy-Augmented Static Slicing'
url: https://www.emergentmind.com/topics/slicet5
type: topic
---

# SliceT5: Copy-Augmented Static Slicing

Searching arXiv for "SliceT5" and directly related papers to ground the article.
arxiv_search(query="SliceT5 OR SLICET5 static program slicing CodeT5", max_results=5, sort_by="relevance")
SLICET5 is a learning-based, end-to-end static program slicer introduced in “SLICET5: Static Program Slicing using Language Models with Copy Mechanism and Constrained Decoding” [2509.17338]. It reformulates static program slicing as a sequence-to-sequence task using lightweight language models, specifically CodeT5 and CodeT5+, and augments them with a copy mechanism and constrained decoding. The target task is backward slicing for Java code: given a slicing criterion, a variable \(v\) at a specific line \([n]\), the goal is to extract the minimal set of statements that semantically influence that variable’s value. The method is designed for the setting in which traditional static slicing tools rely on parsing complete source code and therefore have limited applicability to code snippets that are incomplete or unparsable.

## 1. Definition, scope, and motivation

SLICET5 addresses static program slicing as an extractive code-transformation problem rather than as AST construction, System Dependence Graph construction, and graph reachability. Traditional static slicing tools, including parser- and SDG-based systems such as JavaSlicer and CPP-Slicer, require fully compilable, parsable source code. The paper identifies this as a practical limitation for real-world scenarios in which code is partial, incomplete, or otherwise unparsable. It explicitly motivates slicing by reference to debugging, vulnerability analysis, and program comprehension [2509.17338].

The paper also positions SLICET5 against two classes of learning-based alternatives. First, NS-slicer formulates slicing as statement-level binary classification; in the paper’s characterization, this yields limited method-level context, weak inter-statement dependency modeling, and difficulty distinguishing repeated or identical statements that occur in different positions. Second, foundation-model-based slicers using GPT/Gemma with zero-shot, retrieval-augmented generation, or chain-of-thought prompting often suffer from hallucination, weak logical reasoning over code dependencies, poor exactness, and high deployment cost. SLICET5 is therefore framed as a model that aligns the generation process with the fact that a valid slice must be an exact subpart of the input code.

Two target failure modes organize the method design. The first is inaccurate dependency identification, in which the model includes irrelevant statements or omits necessary ones because it does not precisely capture data and control dependencies. The second is unconstrained generation, in which the model emits extraneous or hallucinated tokens not present in the input, violating the structural integrity of slices. The copy mechanism and constrained decoding are introduced specifically to address these two failures.

## 2. Problem formulation and representation of slices

The paper formalizes the input code snippet to be sliced as
\[
\bm{x} = \{s_1, s_2, \dots, s_i, \dots, s_N; v; [n]\},
\]
where \(s_i\) is a statement in the code snippet \(\{s_1, s_2, \dots, s_N\}\), \(v\) is the variable of interest, and \([n]\) is the line number of \(v\). Each statement is itself represented as a token sequence,
\[
\bm{s_i} = \{ t^{(i)}_1 , t^{(i)}_2 , \dots , t^{(i)}_{M_i}\}.
\]

Given \(\bm{x}\), the slicer models the conditional distribution \(P(\bm{y}|\bm{x})\) and predicts a backward slice
\[
\bm{y} = \{s_{i_1}, s_{i_2}, \dots, s_{i_k}\} \subseteq \{s_1, s_2, \dots, s_{[n]}\}, \quad i_1 < i_2 < \dots < i_k.
\]
This formulation makes two requirements explicit. The first is accuracy: the slice should include all and only the relevant statements. The second is code element preservation: the generated slice must be an exact subpart of the original code, with tokens appearing verbatim and in the same order. In the paper’s framing, this extractive property is why unconstrained open-vocabulary generation is a poor fit for slicing unless it is tightly controlled [2509.17338].

This representation also clarifies what “slice” means operationally in SLICET5. It is not only a dependency set or a list of line numbers. It is a generated code sequence corresponding to the relevant statements from the original snippet. A plausible implication is that method-level seq2seq modeling can exploit broader context than statement-level inclusion classifiers, especially when repeated statements must be disambiguated by their position and surrounding control flow.

## 3. Model architecture and the copy mechanism

SLICET5 is built on Transformer-based seq2seq code language models, specifically CodeT5-base-0.8B and CodeT5+-0.7B, which the paper says were chosen to keep the approach lightweight. The framework adds structural markers during fine-tuning, including `<line_number>`, `</line_number>`, `<code>`, `</code>`, `<criterion>`, `</criterion>`, `<slice>`, and `</slice>`, so that the slicing task structure is explicit. The main reported best model is SliceT5 (CodeT5+) [2509.17338].

The copy mechanism is the first of the two central innovations. It is integrated into the decoder through cross-attention over encoder states. The paper gives the cross-attention weights as
\[
\alpha = \text{softmax}\left(\frac{Q_{dec}K_{enc}^T}{\sqrt{d}}\right),
\]
with \(Q_{dec}\) and \(K_{enc}\) denoting decoder query and encoder key matrices, and \(d\) the hidden dimensionality. These attention weights produce a context vector
\[
h^* = \alpha \cdot V_{enc},
\]
where \(V_{enc}\) is the encoder value matrix.

Generation and copying are then mixed through a scalar generation probability:
\[
p_{gen} = \text{Sigmoid}(W_{gen} \cdot [h^*; x_{dec}] + b_{gen}),
\]
where \([h^*; x_{dec}]\) is the concatenation of the context vector and decoder input. The final output distribution is
\[
P(y) = p_{gen}P_{vocab}(y)+(1-p_{gen})\alpha.
\]

This pointer-generator-style mixture is intended to improve both dependency reasoning and source-faithful extraction. Because slicing is extractive, most output tokens should literally come from the input snippet. The copy path gives the decoder a direct mechanism for reproducing identifiers and code fragments from the source instead of inventing new ones. The paper also argues that the mechanism encourages attention to relevant source elements, thereby improving dependency identification.

Training uses standard cross-entropy over the target slice sequence:
\[
\mathcal{L} = - \sum_{i} p^*_i \log(p_i),
\]
where \(p^*\) is the distribution of the ground-truth slice and \(p\) is the predicted slice distribution. No auxiliary dependency loss or structural loss is reported.

## 4. Constrained decoding: lexical restriction and TSED monotonicity

The second central innovation is constrained beam search, applied only at inference time and described as training-free. The algorithm imposes two constraints: a lexical constraint and a syntactic constraint. At a high level, it computes the set of allowed tokens from the input sequence, runs beam search, masks disallowed tokens so they cannot be generated, expands top-\(K\) candidates, computes TSED before and after adding a token, rejects candidates whose TSED decreases, and keeps the top-\(K\) surviving beams [2509.17338].

The lexical constraint requires that the output may only contain tokens that appear in the original code snippet. Vanilla CodeT5(+) decodes over a fixed vocabulary of 32,100 tokens, whereas a valid slice is extractive and should not contain tokens absent from the source. In the constrained decoder, disallowed tokens are assigned logit score \( -\infty \), so their post-softmax probability becomes zero. This directly prevents invented identifiers, spelling mismatches, hallucinated operators or keywords, and many token-level factuality errors.

The syntactic constraint is based on Tree Similarity of Edit Distance (TSED). The key idea is a monotonicity increasing constraint: since every valid slice is a subsequence of the input code snippet, the TSED score of the partially generated sequence is expected to increase monotonically during decoding as more code elements are generated correctly. If \(\bm{y}\) is the current partial output and \(\bm{y}' = \bm{y} \Vert z_k\) is the candidate after appending token \(z_k\), decoding should preserve
\[
TSED(\bm{x}, \bm{y}') \ge TSED(\bm{x}, \bm{y}).
\]
Candidates are rejected when \(TSED\) decreases. The intended effect is to filter outputs that repeat code fragments, drift out of subsequence order, become structurally inconsistent with the original snippet, or exhibit over-generation.

The paper’s ablation analysis assigns different roles to the three main components. Copy mechanism and lexical constraint are the most impactful; syntactic constraint helps, but is the least impactful of the three. On the out-of-domain LeetCode dataset, removing the copy mechanism drops ExactMatch from 14% to 4%, and removing the lexical constraint drops ExactMatch from 14% to 7%. The syntactic constraint contributes smaller gains, which the authors attribute to the lower frequency of structural errors and to partial mitigation of those errors by copying plus lexical masking.

## 5. Data, training setup, and empirical performance

The experiments focus exclusively on Java backward slicing. Ground-truth static slices were obtained using JavaSlicer. Training uses CodeNet train and validation, with CodeNet test as the in-domain benchmark and LeetCode test-only as the out-of-domain benchmark. CodeNet contains 30.8K training instances, 3.5K validation instances, and 8.7K test instances; LeetCode contributes 100 test instances. Average token counts are 64, 64, and 66 for CodeNet train, validation, and test respectively, and 153 for LeetCode. Average SLOC are 19, 18, and 19 for CodeNet train, validation, and test, and 35 for LeetCode [2509.17338].

Fine-tuning uses AdamW, batch size \(16\), learning rate \(5 \times 10^{-5}\), 1,000 warmup steps, and 10 epochs. Maximum source length and maximum target length are both 256. Inference uses beam search with beam size 3 together with lexical masking and TSED-based rejection.

| Dataset | Setting | SliceT5 (CodeT5+) |
|---|---|---|
| CodeNet | In-domain | Acc-D 98.32, ExactMatch 91.30, CodeBLEU 92.31, TSED 97.06 |
| LeetCode | Out-of-domain | Acc-D 70.85, ExactMatch 14.00, CodeBLEU 60.40, TSED 59.97 |

These results are reported as the best SLICET5 results in the paper. On CodeNet, the best non-SLICET5 baseline is NS-slicer (GraphBERT), with Acc-D 96.51, ExactMatch 85.77, CodeBLEU 89.26, and TSED 90.35. The reported improvement of SliceT5 (CodeT5+) over NS-slicer (GraphBERT) is therefore +1.9% Acc-D, +6.4% ExactMatch, +3.4% CodeBLEU, and +7.4% TSED. On LeetCode, the paper states that SLICET5 improves ExactMatch by up to 27%, corresponding to the increase from 11.00 to 14.00 over the best NS-slicer baseline by ExactMatch.

The comparison with vanilla fine-tuning isolates the effect of the SLICET5 design. For CodeT5+, ExactMatch improves from 87.24 to 91.30 on CodeNet and from 7.00 to 14.00 on LeetCode. For CodeT5, ExactMatch improves from 4.00 to 13.00 on LeetCode. Foundation-model-based prompting baselines perform poorly under ExactMatch: on CodeNet, GPT-4 and Gemma variants are mostly 0.00 ExactMatch, and on LeetCode only GPT-4 (COT) reaches 7.00.

## 6. Robustness to incomplete code, limitations, and disambiguation

A major practical result is performance on incomplete or unparsable code. The paper evaluates three corruption settings: missing class encapsulation, missing semicolons, and missing or unmatched braces. SLICET5 remains the strongest overall method in these scenarios. On LeetCode with missing class encapsulation, SliceT5 (CodeT5+) reaches ExactMatch 14.00, compared with 3.00 for NS-slicer (GraphBERT). With missing semicolons, SliceT5 (CodeT5+) reaches 13.00, compared with 11.00 for NS-slicer (CodeBERT) and 4.00 for NS-slicer (GraphBERT). With missing or unmatched braces, SliceT5 (CodeT5+) reaches 9.00, compared with 4.00 for both NS-slicer baselines. On CodeNet under missing or unmatched braces, SliceT5 (CodeT5+) ExactMatch falls to 79.10, which the paper identifies as the largest degradation among the corruption types because braces define block structure, scope, and control flow [2509.17338].

The paper also states several limitations. Generalization remains limited: maximum LeetCode ExactMatch is only 14%. The study focuses only on Java and on two datasets, CodeNet and LeetCode. The incomplete-code evaluation simulates only three corruption types. The authors fine-tune only lightweight CodeT5 and CodeT5+ variants due to hardware constraints. The paper does not provide explicit runtime overhead numbers for constrained decoding or repeated TSED computation during beam search.

The name “SliceT5” may invite confusion with other slice-oriented papers that are not about static program slicing. “SliceMamba with Neural Architecture Search for Medical Image Segmentation” [2407.08481] proposes SliceMamba, a Mamba-based medical image segmentation architecture centered on a Bidirectional Slice Scan module, and explicitly does not introduce a model named SliceT5. “Slice-level Detection of Intracranial Hemorrhage on CT Using Deep Descriptors of Adjacent Slices” [2208.03403] proposes a two-stage CT pipeline that contextualizes a center slice using adjacent-slice descriptors; it is conceptually related only in the broad sense of slice-sequence contextualization. In the program-analysis literature, by contrast, SLICET5 denotes a copy-augmented, constraint-guided CodeT5/CodeT5+ slicer for exact backward-slice generation from possibly incomplete Java code snippets.

Source: https://www.emergentmind.com/topics/slicet5