ROLex: Resilience & Dynamic Parsing

• ROLex is a dual-natured topic: one system enhances high-performance computing resilience through C/C++ language extensions, and the other improves semantic parsing via expert lexicon retrieval.
• In the HPC context, Rolex introduces tolerance, robustness, and amelioration constructs to allow programs to continue execution despite hardware faults, demonstrating measurable efficiency gains under fault injection.
• For parsing, ROLex employs retrieval-augmented dynamic knowledge-augmented parsing that integrates expert feedback to overcome open-vocabulary failures in natural-language to formal-language tasks.

ROLex denotes two distinct research systems in the arXiv literature. In high-performance computing, "Rolex: Resilience-Oriented Language Extensions for Extreme-Scale Systems" introduces resilience-oriented language extensions for C/C++ that make fault resilience an intrinsic property of application code on future exascale systems (Hukerikar et al., 2016). In semantic parsing and formalization, ROLex denotes a retrieval-augmented parsing method for Dynamic Knowledge–Augmented Parsing (DKAP), designed to handle open-vocabulary constructs by reusing inference-time, expert-provided key–value lexicons without retraining (Hasan et al., 10 Sep 2025). The shared name masks substantially different technical objectives: one system addresses hardware and runtime unreliability in extreme-scale computing, while the other addresses open-vocabulary failures in natural-language-to-formal-language conversion.

1. Terminological scope and research setting

The earlier system, spelled "Rolex" in its title, is motivated by the claim that future exascale HPC systems will be constructed from VLSI devices that will be less reliable than those used today, and that faults will become the norm, not the exception (Hukerikar et al., 2016). Its central premise is that many HPC applications are inherently fault resilient, but that application programmers lack mechanisms to convey this knowledge to the system.

The later system, spelled "ROLex," arises in the context of converting natural language specifications into formal languages such as temporal logic or code, where models fare poorly on open-vocabulary constructs because the required predicates, function names, or variables are not known beforehand (Hasan et al., 10 Sep 2025). Its central premise is that a domain expert can provide the correct constructs at inference time and that this feedback should be reused for future parses without retraining.

A concise comparison clarifies the divergence in purpose.

System	Domain	Core mechanism
Rolex (Hukerikar et al., 2016)	Extreme-scale HPC	C/C++ language extensions, compiler instrumentation, runtime recovery
ROLex (Hasan et al., 10 Sep 2025)	NL-to-formal-language parsing	Retrieval-augmented parsing with a dynamic expert lexicon

This suggests that the name has been independently reused for two systems that both externalize domain expertise, but in very different forms: application-level resilience annotations in one case, and expert key–value lexical feedback in the other.

2. Rolex for extreme-scale systems: resilience model and language design

Rolex augments C/C++ with three families of constructs—Tolerance, Robustness and Amelioration—each targeting a different resilience strategy (Hukerikar et al., 2016). The design is explicitly application-aware: rather than assuming that every detected error requires catastrophic termination, it allows the program to express where errors may be ignored, where bit-precise correctness is required, and where repair routines can be invoked.

The language extensions are exposed through three common syntactic forms. First, type qualifiers are embedded in ordinary declarations, with examples including tolerant(PRECISION=6) double low_precision_var;, robust([CORRECT](https://www.emergentmind.com/topics/correct)) int* critical_ptr;, and heal(recover_matrix()) float A[N] [N];. Second, pragmas mark structured blocks with recovery or redundancy policies, such as #pragma rolex recover-rollback share(x,y) private(tmp) and #pragma rolex robust detect share(buf) private(idx) compare(out). Third, runtime-library routines provide malloc-like and helper calls, including rolex_malloc_tolerant and rolex_validate_robust.

The Tolerance extensions are intended to allow “error elision” or value coercion on parts of state that can absorb perturbations. On floating-point objects, tolerant(PRECISION=p) instructs the runtime to mask bit flips in the lower $(52-p)$ mantissa bits. On unsigned integers, tolerant(MAXIMUS=M) resets any bits above $\lceil \log_2(M+1)\rceil$. The directives recover-rollback and recover-rollforward support local re-execution or skipping when an error is raised inside the block, while malloc_tolerant(size, precision_or_maximus) registers an entire address range for elision so that detected errors on that block are ignored or masked by coercion. The paper formulates an example fault model in which, for a region of $N$ bits under a simple Poisson model,

$$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$

Rolex does not change the physical MTTF but allows a degraded but acceptable state to continue when faults occur in tolerant-annotated regions (Hukerikar et al., 2016).

The Robustness extensions apply application-level DMR/TMR only to variables or code regions whose correctness is critical. robust(DETECT) and robust(CORRECT) can be attached to pointers, loop counters, and critical arrays. The compiler then duplicates or triplicates the object and all statements that manipulate it, inserting comparisons or voting. For structured blocks, #pragma rolex robust detect or correct triggers outlining into a helper function, followed by two or three calls and compare/vote statements over the compare(...) list. On the heap, malloc_robust(size, STRENGTH) allocates redundant copies of the block and instruments pointer dereferences accordingly, while rolex_validate_robust(ptr) triggers explicit validation or voting. The semantics are that, upon a silent data corruption, majority vote restores a correct value or reports a mismatch back to the runtime.

The Amelioration extensions target repair rather than masking or redundancy. heal(recovery_func()) on a declaration registers a callback for errors on that object. recover-rollback ameliorate(recover) and recover-rollforward reinitialize(vars) provide fine-grained region-level recovery by invoking a supplied routine or reinitializing listed variables. malloc_repairable(size, checksum_func) associates an out-of-band checksum or encoding routine; when corruption is detected, the checksum function is used to restore corrupted elements. If the recovery function succeeds, execution resumes; otherwise the runtime aborts (Hukerikar et al., 2016).

3. Rolex implementation: compiler infrastructure and runtime system

Rolex relies on a two-stage, source-to-source transformation flow built on the ROSE compiler framework (Hukerikar et al., 2016). The front end parses the extended grammar for type qualifiers and pragmas and builds a resilience profile containing, for each annotated object, its address, size, attribute, and parameters such as PRECISION, STRENGTH, or recovery function pointers. For tolerant qualifiers it computes bit masks to elide or coerce. For robust qualifiers and directives it outlines structured blocks into new functions, duplicates or triplicates declarations and statements touching robust objects, and inserts calls to runtime library routines including __rolex_preserve_state(), __rolex_restore_state(), __rolex_copy(), __rolex_compare(), __rolex_jmp_fwd(), and __rolex_jmp_back(). For heal qualifiers it inserts a registration call __rolex_register(obj, recovery_func). The back end then compiles the transformed C/C++ code with any standard compiler such as GCC or ICC; no special hardware or ISA changes are required.

The runtime system consists of a user-level library plus a small kernel module to intercept machine-check or ECC interrupts. At startup, __rolex_initialize() populates a Dynamic Resilience Map (DRM) from the resilience profile with entries of the form address range to error strategy and parameters. As memory is allocated or freed via Rolex routines, DRM entries are added or removed dynamically. Uncorrectable ECC errors or explicit interrupts are caught by a lightweight Linux kernel module and forwarded as a POSIX signal to the application. The RTL signal handler looks up the faulting address in the DRM and consults a decision tree to determine which strategy to invoke.

The recovery actions are annotation-specific. In a tolerant region, the runtime masks or coerces corrupted bits and returns to the original program counter. For recover-rollback or recover-rollforward, it invokes __rolex_jmp_back() or __rolex_jmp_fwd() and restores share(...) variables via __rolex_restore_checkpoint(). In a robust region, it calls __rolex_compare() or performs majority voting, then corrects the in-memory copy and continues; on irrecoverable mismatch, it aborts or falls back. In a heal region, it invokes the user’s recovery function and either resumes or aborts depending on the outcome. Because recovery is interrupt-driven and requires no polling, the fault-free overhead is described as limited to the inserted instrumentation, approximately $5$–$15\%$ depending on annotation density (Hukerikar et al., 2016).

A plausible implication is that the system’s main novelty is not merely the syntax of the annotations but the end-to-end coupling between source-level resilience declarations, compiler-generated duplication and checkpointing, and runtime address-range dispatch via the DRM.

4. Rolex evaluation and representative use-cases

The evaluation uses a Linux cluster with dynamic, software-based fault injection as a stand-in for hardware ECC interrupts or SDCs (Hukerikar et al., 2016). Each application runs for at least $20$ minutes so that, at the chosen fault rates, between $1$ and $20$ faults occur per run. Five MTTF scenarios are tested: $15$ min, $\lceil \log_2(M+1)\rceil$0 min, $\lceil \log_2(M+1)\rceil$1 min, $\lceil \log_2(M+1)\rceil$2 min and $\lceil \log_2(M+1)\rceil$3 min. Each benchmark and fault-rate combination is exercised $\lceil \log_2(M+1)\rceil$4 times with randomized fault sites.

The benchmarks are organized by annotation family. For Tolerance, the evaluated applications are HPCC Random Access, 3D rendering, and Molecular Dynamics. The main table in HPCC Random Access is allocated with malloc_tolerant; the frame buffer in 3D rendering is declared tolerant; and the position, velocity, and acceleration arrays in Molecular Dynamics use tolerant(PRECISION=26). For Robustness, the paper evaluates Graph500 BFS, where all pointer arrays are declared robust, and Algebraic Multigrid, where pointer arrays are robust and intermediate grids are allocated tolerant. For Amelioration, the paper evaluates DGEMM with operand matrices allocated via malloc_repairable and row/column checksum, Conjugate Gradient with the same mechanism plus roll-forward CG iteration as an amelioration block, and Self-Stabilizing CG with roll-back plus a custom stabilizer in the amend clause.

The outcome categories are defined explicitly. Correct Completion means that the application finishes and the result is within user-defined error bounds, such as total energy within $\lceil \log_2(M+1)\rceil$5. Fatal Failure includes crashes, unhandled errors, or unacceptable results. Benign Fault refers to an error in unannotated but non-critical memory that still finishes correctly without intervention. The study also distinguishes Detected & Recovered from Undetected & Catastrophic.

The reported resilience metrics vary by workload and annotation strategy. For tolerance, Figure 1 shows at least $\lceil \log_2(M+1)\rceil$6 success on HPCC Random Access up to $\lceil \log_2(M+1)\rceil$7 fault/min, approximately $\lceil \log_2(M+1)\rceil$8 on 3D rendering, and approximately $\lceil \log_2(M+1)\rceil$9 on Molecular Dynamics at $N$0 fault/$N$1 min, dropping to below $N$2 at $N$3 fault/min. For robustness, Figure 2 shows that Graph500 catches and corrects approximately $N$4 of SDCs on pointers, while Algebraic Multigrid sees a higher benign fraction due to tolerant grids. For amelioration, Figure 3 shows DGEMM at approximately $N$5 correct at $N$6 fault/$N$7 min, dropping to approximately $N$8 at $N$9 fault/min; Conjugate Gradient at approximately $$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$0; and Self-Stabilizing CG at approximately $$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$1 (Hukerikar et al., 2016).

The paper defines workload efficiency as

$$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$2

Tolerance codes pay approximately $$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$3–$$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$4 extra time as faults become frequent, robustness codes incur approximately $$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$5 steady overhead plus small interrupt latency, and amelioration codes can reach up to $$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$6 overhead when faults are very frequent but drop to $$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$7–$$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$8 when fault rates are moderate.

The illustrative code examples clarify intended usage. A simple solver declares tolerant(PRECISION=6) double x[1000000]; and wraps an update step in #pragma rolex recover-rollforward share(i) private(tmp), so that on a detected ECC interrupt the runtime skips the body and continues. A sparse-graph example declares CSR arrays as robust(CORRECT) and uses #pragma rolex robust correct ... compare(dist[]), so that a silent pointer flip is detected by TMR and majority-voted back before a segmentation fault occurs. In DGEMM, rolex_malloc_repairable associates matrices with rowcol_checksum, and the runtime repairs A or B before resuming the multiply. The contrast stated in the paper is direct: without Rolex, a single ECC uncorrectable error or SDC typically crashes or yields wrong results; with Rolex, the runtime masks or corrects the error locally, or rolls back the offending block, allowing the rest of the simulation to proceed (Hukerikar et al., 2016).

5. ROLex for Dynamic Knowledge–Augmented Parsing

ROLex in the later sense is a retrieval-augmented parsing approach proposed to address Open-Vocabulary Constructs (OVCs) in formalizing specifications and code (Hasan et al., 10 Sep 2025). In this setting, a model may encounter domain- or user-specific predicates, function names, or variables that were absent from training. The motivating examples include an NL$$\mathrm{MTTF}_{\mathrm{block}} = \frac{\mathrm{MTTF}_{\mathrm{bit}}}{N}.$$9LTL parser that has never seen the predicate is_regular and a text-to-Python-code model that defaults to a SciPy solver when the user’s environment requires numpy.linalg.solve.

The broader problem formulation is Dynamic Knowledge–Augmented Parsing (DKAP). In DKAP, an expert supplies corrective feedback the first time an unknown construct is mis-parsed; the feedback is stored in a growing, in-memory lexicon and reused automatically on subsequent encounters. The model must retrieve the relevant lexicon entries from a dynamically growing key–value store and condition its final semantic parse on both the input sentence and the retrieved expert knowledge.

ROLex instantiates DKAP with two learned modules: a retriever $5$0 and a generator $5$1. The retriever ranks key–value pairs

$5$2

for relevance to the current NL query $5$3. The generator emits the formal-language parse $5$4 conditioned on the input $5$5 and the top-$5$6 retrieved entries

$5$7

Keys are generic, idiomatic NL phrases describing a construct, such as “A is a regular file,” while values are the exact formal-language token or snippet, such as is_regular(A). After parsing $5$8, any newly corrected mappings are appended:

$5$9

The retriever uses a dense, bi-encoder architecture, for example a BGE-based sentence transformer. With embeddings $15\%$0 and $15\%$1, the retriever is fine-tuned with an InfoNCE-style contrastive loss over positive pairs and in-batch negatives:

$15\%$2

At inference, ranking is performed by the inner product $15\%$3 over the lexicon entries.

The generator is a seq2seq model such as T5 or Code-T5, fine-tuned to maximize

$15\%$4

In a few-shot setting, the paper instead prompts a large LLM such as ChatGPT or GPT-4 with the NL input plus the retrieved key–value pairs as context. This suggests that the nonparametric lexicon is intended to complement both conventional seq2seq models and prompt-based LLMs rather than being tied to a single generator family.

6. ROLex training, evaluation paradigm, results, and limitations

A major difficulty for ROLex is data construction for retrieval-augmented parsing (Hasan et al., 10 Sep 2025). For NL2LTL in the NFS domain, the paper uses a custom CFG that simultaneously generates natural-language fragments and corresponding LTL templates, and then adds distractor lexicon entries alongside the ground-truth ones. For NL2Code and NL2CMD, aligned corpora from CoNaLa and TLDR are enriched by mining official documentation, using roughly the first $15\%$5 characters of each library or command documentation string as keys and the function or command name as the value.

To improve generator attention to the relevant subset of retrieved knowledge, four schemes are evaluated. Basic trains on $15\%$6 only. Extra Supervision additionally trains on the relevant subset $15\%$7 so that

$15\%$8

Multi-Task augments the objective so that the generator first emits the list of relevant keys and then the full parse:

$15\%$9

Transfer first fine-tunes the generator to recover $20$0 from $20$1, then fine-tunes again on parse generation. Empirically, multi-task and transfer learning give the best OVC F1-scores, approximately $20$2–$20$3 points versus approximately $20$4–$20$5 for the basic schemes.

The evaluation paradigm is explicitly sequential. The model is tested on a stream $20$6 with an initially empty knowledge base. At each step it retrieves $20$7 from the current KB, generates a parse, compares it to gold, extracts any missing mappings from $20$8, and updates the KB. The three tasks are NL2LTL, NL2Code, and NL2CMD, with unseen OVCs in the test split. Metrics include BLEU for whole-parse fidelity and OVC Precision/Recall/F1 for exact generation of the expert-provided constructs.

The reported improvements are task-dependent but substantial. For fine-tuned generators, on NL2LTL, T5-base improves from BLEU $20$9 and OVC F1 $1$0 with ROLex. On NL2Code, Code-T5-base improves from BLEU $1$1 and OVC F1 $1$2. On NL2CMD, Code-T5-base improves from BLEU $1$3 and OVC F1 $1$4. For few-shot LLMs on NL2LTL, ChatGPT improves from BLEU $1$5 and OVC F1 $1$6, while GPT-4 improves from BLEU $1$7 and OVC F1 $1$8. The paper states that even three in-context examples suffice for ROLex to halve the OVC error rate.

Retriever quality is a central bottleneck. BM25 achieves only R@10 approximately $1$9–$20$0 across tasks. Off-the-shelf BGE-large reaches R@10 approximately $20$1–$20$2, and fine-tuned BGE-large approximately $20$3–$20$4. Better retrieval correlates strongly with higher downstream OVC F1. Estimated expert-effort savings from correction reuse reach up to $20$5 for NL2LTL with fine-tuned models, $20$6 for NL2Code, $20$7 for NL2CMD, and $20$8 for GPT-4 few-shot NL2LTL.

The limitations are stated directly. Retriever recall remains modest, with less than $20$9 at R@10. Generator hallucination of spurious predicates still accounts for approximately $15$0 of OVC errors in some analyses. Building an initial lexicon requires nontrivial engineering or documentation mining in each new domain. The future directions proposed include generation-informed retrieval, interactive refinement that queries the expert only when uncertain, universal lexicon-typing schemes, and tighter integration with LLMs. A plausible implication is that ROLex is best understood not as a closed-form parser, but as an interactive semantic parsing framework in which external symbolic memory compensates for parametric blind spots (Hasan et al., 10 Sep 2025).