On-the-Fly Kernel: Dynamic Runtime Adaptation

• On-the-Fly Kernel is a dynamic runtime strategy that adapts kernel behavior through mechanisms like eBPF-based programmability, live compartmentalization, and runtime retraining.
• It employs static analysis, uncertainty estimation, and narrow interfaces to ensure safety while selectively engaging high-cost computational resources.
• Applications span programmable OS kernels, live security enforcement, execution translation on low-power cores, and adaptive surrogate models in scientific simulations.

Searching arXiv for the cited works to ground the article in current arXiv records. arXiv search: "(Gbadamosi et al., 2024) The eBPF Runtime in the Linux Kernel" In the literature surveyed here, “on-the-fly kernel” does not denote a single formalism. It refers to a family of runtime-specialized mechanisms in which kernel behavior is inserted, fused, retrained, translated, or otherwise adapted during execution rather than fixed entirely in advance. The term appears in at least three technically distinct settings: operating-system kernels made dynamically programmable through eBPF; live security enforcement and compartmentalization of kernel subsystems; and computational or statistical kernels that are optimized or retrained during execution, including GPU kernels and kernel-based surrogate models for molecular simulation (Gbadamosi et al., 2024). A common theme is immediate runtime action under tight correctness constraints, typically mediated by static analysis, uncertainty estimation, narrow interfaces, or conservative fallback paths (Wang et al., 2024).

1. Scope and research usages

The phrase is best understood as a runtime systems pattern rather than a single architecture. In one usage, Linux behaves like an “on-the-fly kernel” because eBPF embeds a safe virtual machine directly inside the kernel and permits programs to be loaded, verified, JIT-compiled, attached to hooks, detached, and updated at runtime (Gbadamosi et al., 2024). In another usage, runtime kernel compartmentalization instruments a live kernel after a threat is disclosed, enforcing control-flow integrity, data integrity, and interface checks without reboot or recompilation (Wang et al., 2024). In a third usage, computational kernels are not launched or materialized eagerly; instead, they are buffered, fused, streamed, or specialized over a wider execution window, as in AsyncTaichi’s inter-kernel optimizer and E2Former-V2’s fused Triton attention kernel (Hu et al., 2020). A further extension of the idea appears in kernel-based machine learning, where surrogate models built from SOAP or Coulomb-matrix descriptors are retrained on the fly during molecular dynamics and fall back to electronic-structure calculations when uncertainty or confidence criteria demand it (Kumar et al., 2024).

Domain	Kernel meaning	Runtime mechanism
Linux eBPF	OS kernel	Verified program load and hook attachment
O2C	OS kernel security boundary	On-the-fly compartmentalization with eBPF
Transkernel	Monolithic kernel execution	Cross-ISA DBT on a peripheral core
AsyncTaichi / E2Former-V2	GPU or compute kernel	Buffered optimization or fused streaming execution
MLFF / KRR dynamics	Kernel method in ML	On-the-fly retraining with uncertainty-triggered fallback

This diversity matters because it prevents a common misunderstanding: “on-the-fly” does not imply unrestricted dynamism. In all of these systems, runtime flexibility is paired with a gatekeeper. In eBPF, the gatekeeper is the verifier; in O2C, it is verifier-checked instrumentation plus explicit policy; in transkernel execution, it is hot-path specialization plus CPU fallback; and in on-the-fly kernel learning for atomistic simulation, it is Bayesian uncertainty or confidence-region detection (Gbadamosi et al., 2024).

2. Dynamically programmable operating-system kernels

The clearest operating-system realization is eBPF. The Linux kernel implements an in-kernel runtime through the bpf(2) system call interface, exposing an abstract virtual machine with a 64-bit instruction set, 11 registers (r0–r10), and a fixed-size stack (Gbadamosi et al., 2024). Programs are written in higher-level languages, typically compiled with LLVM/clang to ELF objects targeting bpf, and then loaded into the kernel via BPF_PROG_LOAD. If accepted, the program is JIT-compiled to native instructions and attached to a hook such as XDP, tracepoints, cgroup hooks, LSM hooks, kprobes/uprobes, socket hooks, or scheduler callbacks. Links and file descriptors manage object lifetime; in the paper’s example, an XDP program attached to eth0 can be detached simply by closing the link descriptor (Gbadamosi et al., 2024).

The safety boundary is the verifier. It is a static analyzer whose safety goals include memory safety, type safety, resource safety, information-leak safety, data-race freedom for kernel state, termination, deadlock freedom, and preservation of execution-context invariants (Gbadamosi et al., 2024). Its symbolic state is summarized as

$\hat{S} = (\{stmt\}, \sigma, \pi),$

where $\{stmt\}$ is the executed instruction sequence along a path, $\sigma$ maps registers and stack locations to symbolic or concrete values with type information, and $\pi$ records path metadata such as liveness, precision, resource, and alignment state. For numeric reasoning, the verifier uses abstractions such as tnums, and BTF supplies compact type metadata so that object layouts, structure sizes, prototypes, and annotations can be interpreted statically (Gbadamosi et al., 2024).

Linux implements verification as four passes: CFG validation, exhaustive symbolic execution, post-verification optimizations and fixups, and JIT compilation for each subprogram (Gbadamosi et al., 2024). This yields a hybrid model in which the kernel remains in place while narrowly scoped verified programs alter behavior in concert with kernel mechanisms and state. Production use already spans XDP and TC packet processing, DDoS mitigation, load balancing, flow redirection, packet rewriting, profiling and tracing through perf events and kprobes, LSM BPF for programmable security policy, HID-BPF, SCHED-EXT and ghOSt-related scheduling work, and XRP for storage acceleration (Gbadamosi et al., 2024).

The main limitations are also runtime-specific. The verifier faces path explosion and instruction complexity limits on branch-heavy programs and loops; full formal verification of the verifier and JITs remains open; usability is constrained by hook selection, program-type restrictions, and version compatibility; and unprivileged use is restricted by default because of a history of exploitation, with operations gated by capabilities such as CAP_BPF, CAP_NET_ADMIN, and CAP_PERFMON (Gbadamosi et al., 2024). These constraints show that an on-the-fly kernel is not a replacement kernel, but a verified programmable substrate layered onto the existing one.

3. On-the-fly compartmentalization and live remediation

O2C develops the security interpretation of the idea: a vulnerable kernel component can be compartmentalized at runtime rather than before boot or at compile time (Wang et al., 2024). The stated motivation is immediate remediation after disclosure, when subsystem attribution may be known but a patch is not yet available. Existing compartmentalization systems are characterized as offline because they require pre-reserved memory, hypervisor or hardware setup, or kernel recompilation and reboot. O2C instead uses eBPF to instrument enforcement logic into the running kernel and maintain system availability during the transition (Wang et al., 2024).

The system is organized into three phases. Phase $(-1)$ performs preparation: code analysis, object profiling, model training, and synthesis of eBPF enforcement programs. Phase $0$ is the transition period, in which eBPF programs are attached, private stack and heap are created, control-flow integrity and data-integrity checks are enforced, and machine-learning-based audition is used for untracked objects that predate activation. Phase $1$ is steady state, where all objects are tracked and ML audition is disabled (Wang et al., 2024). The transition phase is not merely incidental: profiling in the paper found that more than 3340 kernel objects had lifetimes longer than one minute, so pre-existing objects can remain security-relevant long enough to matter operationally (Wang et al., 2024).

The enforcement policy covers three properties: control-flow integrity, data integrity, and authorized arguments and return values (Wang et al., 2024). A code analyzer identifies indirect transfers, memory accesses, and subject-switching sites. At runtime, eBPF programs validate indirect call, jump, and return targets against legal target sets stored in BPF maps; memory accesses are checked against expected global, stack, or heap regions; and interface arguments and return values are checked to prevent confused deputy and Iago-style attacks. Private stack and private heap regions are created with helper support, BPF maps, the buddy allocator, SLAB/SLUB caches, and vmalloc, depending on allocation size and type (Wang et al., 2024).

The distinctive difficulty is object typing during the transition, when live heap objects were allocated before tracking began. O2C therefore embeds a decision-tree model into eBPF. Training data are collected globally across the kernel: at allocation, object address and call trace are recorded and the type inferred; at free, object contents are dumped and labeled by address lookup. The paper uses Syzkaller and object-driven fuzzing ideas from GREBE to diversify contents (Wang et al., 2024). Decision trees are chosen over random forests and neural networks because they fit tabular object-content data, are explainable, and comply with eBPF constraints such as no floating-point support, limited instruction count, limited stack, and no dynamic heap. The tree is converted into five arrays—childrenLeft, childrenRight, feature, threshold, and value—stored in BPF maps. Floating-point thresholds are rounded down to integers, and a pre-reserved huge pool in a BPF map compensates for stack and heap limits during feature handling (Wang et al., 2024).

The evaluation examines 84 vulnerabilities from IPv6, net/sched, and netfilter, and references analysis over 400 vulnerabilities (Wang et al., 2024). For type-granularity classification, the reported decision-tree accuracies are 96.88% for IPv6, 80.48% for net/sched, and 89.47% for netfilter, with macro-F1 scores of 75.56, 71.04, and 78.17 respectively; for compartment granularity, accuracy is near-perfect at 99.99%, 99.93%, and 99.92% (Wang et al., 2024). System-wide overhead measured by LMbench is roughly within $-1.26\%$ to $3.81\%$, the ML audition adds unnoticeable overhead, and scalability does not degrade significantly as compartment size increases (Wang et al., 2024). A plausible implication is that, within the eBPF execution model, explainability and deployability can dominate pure classifier accuracy when remediation must be injected into the live kernel.

4. Translated and offloaded kernel execution

A different interpretation of an on-the-fly kernel is execution migration rather than in-kernel programmability. Transkernel addresses suspend and resume phases of a monolithic kernel on battery-powered embedded devices, arguing that this control-heavy, wait-dominated work is mismatched to a high-performance CPU and better suited to a low-power peripheral core (Guo et al., 2018). The proposed structure offloads device suspend and device resume to a lightweight virtual executor that translates stateful kernel execution through cross-ISA DBT, emulates a small set of stateless kernel services behind a narrow stable binary interface, specializes for hot paths, and exploits ISA similarities (Guo et al., 2018).

The design principle is “translate stateful code; emulate stateless services” (Guo et al., 2018). Stateful components include drivers, driver libraries, kernel libraries, selected kernel services, deferred work, sleepable locks, allocator fast paths, and interrupt-handling continuation code. Emulated services include scheduler behavior for DBT contexts, early interrupt handling, interrupt-controller behavior, spinlocks, and delay and timekeeping primitives such as udelay(), msleep(), and jiffies. The interface between translated code and emulation is intentionally narrow: 12 Linux kernel functions and one kernel variable, jiffies (Guo et al., 2018). Hot-path specialization is central; if execution leaves the hot suspend/resume path, ARK migrates back to CPU execution.

The prototype runs Linux v4.4 on a Cortex-A9 CPU and a Cortex-M3 peripheral core (Guo et al., 2018). Translation is optimized for the ARMv7A-to-ARMv7M case. Out of 558 ARMv7A instructions, about 80% are identity-translated or have nearly identical counterparts, about 15% need small amendment sequences, and only 27 instructions have no direct counterpart and require manual translation rules. Registers and condition flags are passed through directly, guest stack is used in place, and control-transfer optimization stores code-cache return addresses directly to reduce exits to the DBT engine (Guo et al., 2018). The paper’s example translates three ARMv7A instructions into seven ARMv7M instructions, whereas a baseline QEMU-style port would produce 27 (Guo et al., 2018).

The quantitative result is that slower execution can still reduce total energy. ARK’s average overhead relative to native CPU execution is $2.7\times$, with $\{stmt\}$0 for suspend and $\{stmt\}$1 for resume, versus $\{stmt\}$2 for the baseline DBT (Guo et al., 2018). Yet total system energy drops by 34% because the peripheral core’s power is dramatically lower during the long idle periods characteristic of suspend/resume (Guo et al., 2018). In 1000 runs, fallback occurred only four times, all due to WiFi firmware issues, and migration costs were reported as about $\{stmt\}$3 to rewrite code-cache addresses on the stack, $\{stmt\}$4 to flush cache, and $\{stmt\}$5 to wake the CPU via IPI (Guo et al., 2018). This suggests that an on-the-fly kernel can also mean selective execution relocation of existing kernel binaries, not merely runtime extension of kernel logic.

5. Computational kernels: buffering, fusion, and streaming execution

In GPU and compiler research, the “kernel” is an execution unit rather than the operating system. AsyncTaichi argues that sparse programs should not be optimized one kernel at a time; instead, the runtime buffers multiple kernels, constructs a domain-specific state-flow graph, and applies inter-kernel optimizations across a larger execution window (Hu et al., 2020). The graph models value state, mask state, list state, and allocator state, each tagged with a version number, and uses state-flow chains to represent dependencies. Kernels invoked from Python are queued and only flushed on synchronization events or explicit ti.async_flush() calls; at flush time, the runtime builds the graph, applies optimization passes, and then launches the optimized tasks (Hu et al., 2020).

The main sparse-domain optimizations are elimination of unnecessary voxel list generation and removal of voxel activation checks (Hu et al., 2020). Since list generation is idempotent given unchanged parent list and mask state, later list-generation tasks can be removed if topology has not changed between struct-for traversals. Activation checks can be demoted when the optimizer infers that target voxels are already active or that writes do not introduce new active voxels. These sparse-specific simplifications then enable classical optimizations such as task fusion and dead store elimination. Without code modification, the system reports 4.02× fewer kernel launches and a 1.87× geometric-mean speedup on GPU benchmarks, with microbenchmark improvements of 2.30× on CUDA, 2.14× on x64, and 3.73× fewer launched tasks on CUDA (Hu et al., 2020). In MGPCG, first-iteration startup time improves from 9.0 s to 3.7 s due to parallel compilation (Hu et al., 2020).

E2Former-V2 pushes the same logic further toward hardware-aware fusion. Its On-the-Fly Equivariant Attention is implemented as a fused Triton kernel that streams over neighbors of each target atom and avoids materializing edge tensors in HBM (Huang et al., 23 Jan 2026). For each target node $\{stmt\}$6, the kernel maintains a running max $\{stmt\}$7, normalizer $\{stmt\}$8, and accumulator $\{stmt\}$9, updating them online as neighbors are traversed; scores, bias addition, softmax normalization, and value accumulation are all fused (Huang et al., 23 Jan 2026). The paper emphasizes that gathered keys, values, and attention weights are never materialized as dense edge tensors, reductions over the neighbor dimension are performed on chip, and each key and value vector is loaded exactly once per interaction. Combined with Equivariant Axis-Aligned Sparsification, which reduces dense tensor contractions to sparse parity re-indexing operations after an $\sigma$0 basis change, the fused kernel reports an approximately 20× improvement in TFLOPS relative to a naïve PyTorch implementation, while EAAS gives a $\sigma$1 speedup for the equivariant tensor product stage (Huang et al., 23 Jan 2026).

A common misconception is that these are merely implementation details. In fact, the papers frame them as algorithmic reorganizations: “assemble, reduce, merge, continue” in OpenLoops-style on-the-fly reduction, queue-then-optimize in AsyncTaichi, and visit-neighbor-then-accumulate in fused sparse attention (Buccioni et al., 2018). The unifying principle is that runtime structure is exploited before intermediate state becomes too large or too expensive to store.

6. Kernel methods retrained during simulation

In scientific computing and molecular dynamics, “kernel” may refer to the statistical kernel of a surrogate model. The shock Hugoniot framework of Shao and coauthors computes Hugoniots using on-the-fly machine learned force fields trained from Kohn–Sham DFT data (Kumar et al., 2024). The MLFF represents the electronic free energy as a sum of atomic contributions,

$\sigma$2

with SOAP descriptors, a polynomial kernel, and Bayesian linear regression for the weights (Kumar et al., 2024). Because the descriptors depend explicitly on atomic coordinates, forces and stresses are obtained by differentiation. Bayesian prediction uncertainty is the trigger for retraining during MD: when force uncertainty exceeds a dynamic threshold $\sigma$3, a new DFT calculation is performed, the training set is augmented, and the kernel model is retrained (Kumar et al., 2024).

The framework supplements the free-energy model with a simple linear regression between electronic internal energy and free energy because the Hugoniot requires internal energy (Kumar et al., 2024). The shock condition is the standard Rankine–Hugoniot relation

$\sigma$4

and Hugoniot points are obtained by linear interpolation in density versus the residual of the relation, with reported linear fits of $\sigma$5 (Kumar et al., 2024). For each temperature, the EOS is sampled by isokinetic $\sigma$6 MD with a Gaussian thermostat for 10,000 steps, the first 1,000 discarded for equilibration, and the rest averaged to reduce pressure noise to below 0.1% (Kumar et al., 2024). On carbon, the maximum discrepancy along the Hugoniot is 1.9% in pressure and 0.4% in density, average MLFF prediction errors over DFT steps are 1.4% in pressure and 0.005 hartree/atom in internal energy, and Kohn–Sham Hugoniot calculations are accelerated by up to two orders of magnitude, with an average speedup of 62× and only 0.46% to 1.38% of MD steps requiring DFT (Kumar et al., 2024). Across 14 FPEOS materials, average differences are about 0.8% in density and 2.5% in pressure, and for compounds the linear mixing approximation error falls below 1% above 200 kK, supporting the conclusion that inter-element interactions weaken with increasing temperature (Kumar et al., 2024).

A related use appears in on-the-fly nonadiabatic molecular dynamics with kernel ridge regression potential energy surfaces (Hu et al., 2018). For 6-aminopyrimidine, separate KRR models for the adiabatic states $\sigma$7, $\sigma$8, and $\sigma$9 use Coulomb-matrix descriptors and a Gaussian RBF kernel (Hu et al., 2018). Most geometries are evaluated by the ML-PES, while fallback to CASSCF is triggered for out-of-confidence geometries or for geometries near the $\pi$0 conical intersection seam, operationalized by an energy gap $\pi$1 eV (Hu et al., 2018). Only about 3.9% of geometries require CASSCF instead of ML prediction, test-set mean absolute errors are 0.226, 0.411, and 0.749 kcal/mol for $\pi$2, $\pi$3, and $\pi$4, and a 2000-step trajectory drops from about 50 hours with pure on-the-fly CASSCF to about 4.7 hours with ML-PES plus selective fallback (Hu et al., 2018). The fitted excited-state lifetime is about 335 fs from ML-PES dynamics versus about 347 fs from the CASSCF benchmark (Hu et al., 2018).

Taken together, these studies show that “on-the-fly kernel” in scientific computing often means a kernel method that is trusted only locally and provisionally. The surrogate is updated when uncertainty becomes too large, and the expensive first-principles method remains the arbiter of correctness.

7. Cross-cutting design principles and limitations

Across operating systems, compiler runtimes, and scientific simulation, several design regularities recur. First, runtime specialization is always bounded by a conservative admission or fallback mechanism. eBPF rejects any program the verifier cannot prove safe; O2C relies on verifier-checked probes and disables ML audition after transition; ARK falls back to the CPU on cold branches; ML-PES and MLFF frameworks return to CASSCF or Kohn–Sham DFT for out-of-confidence or high-uncertainty configurations (Gbadamosi et al., 2024). This suggests that on-the-fly kernels are rarely fully autonomous; they are layered accelerators or enforcers around a trusted baseline.

Second, state representation is explicit and often externalized. eBPF exposes programs, maps, links, helpers, and BTF as first-class kernel objects with file-descriptor lifetimes (Gbadamosi et al., 2024). AsyncTaichi models values, masks, lists, and allocator state with versioned edges in an SFG (Hu et al., 2020). O2C stores target sets, object metadata, and decision-tree arrays in BPF maps (Wang et al., 2024). E2Former-V2 replaces materialized edge tensors with online state variables $\pi$5, $\pi$6, and $\pi$7 in a streaming reduction (Huang et al., 23 Jan 2026). On-the-fly execution is therefore usually accompanied by an unusually explicit state model.

Third, performance gains arise primarily from avoiding unnecessary global work. eBPF avoids kernel replacement or bypass, O2C avoids reboot and recompilation, ARK avoids waking the main CPU for suspend/resume work, AsyncTaichi avoids redundant list generation and kernel launches, and E2Former-V2 avoids HBM traffic from edge materialization (Gbadamosi et al., 2024). In the MLFF context, only a small fraction of MD steps require DFT; in the KRR nonadiabatic context, only a small fraction of geometries require CASSCF (Kumar et al., 2024). The practical value of the on-the-fly approach is thus tied less to asymptotic novelty than to selective engagement of expensive machinery.

The limitations are equally consistent. Verifier scalability, branch-path explosion, and formal soundness remain open problems for eBPF (Gbadamosi et al., 2024). O2C is constrained by the eBPF instruction model and can suffer larger performance loss on large compartments and workloads with frequent memory accesses (Wang et al., 2024). Transkernel depends on ISA similarity, hot-path stability, and a narrow ABI (Guo et al., 2018). AsyncTaichi requires an execution window wide enough to expose inter-kernel opportunities (Hu et al., 2020). On-the-fly ML surrogates depend on the adequacy of confidence detection, the simplicity of auxiliary regression models, and the quality of DFT-selected updates (Kumar et al., 2024). A plausible implication is that the “on-the-fly” strategy is strongest when structure is repetitive, local, and interruptible, but weaker when correctness depends on globally entangled state or when the runtime gatekeeper itself becomes the bottleneck.