Skip to content

Code Mobility

The capability to transfer executable code, optionally with data and suspended execution state, between hosts or runtime environments so computation begins or continues at the destination.

Version
v1 · 2026-09-28 · History
Domain-specific #
8516
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomains
Distributed Systems, Mobile Code → Computer Science & Software Engineering
Aliases
Mobile code, Computational code mobility, Code and execution-state mobility

Core Idea

Code mobility changes where computation is executed by moving the executable unit across a host or application boundary. Weak mobility transfers code and associated data but starts it at a defined destination entry point. Strong mobility additionally captures execution state—such as the control point and relevant runtime context—so the computation can resume rather than restart.

How would you explain it like I'm…

The Traveling Program

Usually a computer program stays on one computer and you send it things to work on. With code mobility, the program itself travels to a different computer and runs there. Sometimes it starts over from the beginning when it arrives, and sometimes it remembers exactly where it stopped and keeps going, like picking up a game from your saved spot.

Programs That Move to Run

Code mobility means moving the program itself, not just the information, from one computer to another so it runs in a new place. In weak mobility, the code and its data travel, and the program starts fresh from a set starting point on the new computer. In strong mobility, it also brings where it was in its work, so it can continue instead of restarting. The receiving computer needs a way to run the code and rules that limit what visiting code is allowed to do. Sending data to a program that is already installed somewhere is not code mobility.

Migrating Executable Code

Code mobility changes where a computation runs by moving the executable code itself across a boundary between machines or applications. In weak mobility, the code and its data are transferred and the code starts at a set entry point at the destination. In strong mobility, the running state is also captured, such as where it was in the program and relevant runtime context, so the computation resumes rather than restarting. Styles differ by direction: remote evaluation sends code to a remote host to run; code on demand downloads code to the machine that asked for it; a mobile agent migrates among hosts, either by its own decision or on instruction. Every style needs a destination runtime that can rebuild the code's dependencies and a security model limiting what arriving code can do. Just sending data to a program already installed elsewhere is distributed computing, but not code mobility.

 

Code mobility is the relocation of computation by moving the executable unit across a host or application boundary, so that code, not just data, changes location. Weak mobility transfers code and associated data and starts execution at a defined entry point on the destination. Strong mobility additionally captures execution state, including the control point and relevant runtime context, allowing the computation to resume where it left off. Styles are distinguished by who initiates and in which direction code moves: remote evaluation ships code to a remote host for execution, code on demand fetches code to the requester, and mobile agents migrate among hosts autonomously or under instruction. All styles depend on a destination runtime able to reconstruct the code's dependencies and on an authority model that constrains the capabilities of incoming code. The boundary case clarifies the concept: sending only data to a fixed, pre-installed program is distributed computation, not code mobility.

Scope of Application

  • Code on demand. A client obtains executable code from a provider and starts it locally under a destination policy.
  • Remote evaluation. A client ships code and data to execute near remote resources or services.
  • Mobile agents. An encapsulated computation moves among hosts, with weak or strong state semantics.
  • Process migration. A runtime checkpoints and resumes a running process on another compatible host.

Clarity

A mobility claim should list the executable unit, origin, destination, transferred data, transferred control state, dependencies, and restart or resume semantics. It should also distinguish logical mobility from implementation: a container image may move code and filesystem state without preserving a live instruction pointer, while a process checkpoint may preserve much more. The trust boundary is part of the design, not a separate afterthought.

Manages Complexity

Mobility can replace many application-specific remote operations with one general ability to relocate behavior. This can reduce network traffic or extend clients dynamically, but it transfers dependency management, resource accounting, and security to the destination. Packaging, sandboxing, capability restriction, and observable failure semantics are therefore part of making the abstraction usable at scale.

Abstract Reasoning

  1. Define the unit of computation and why relocation is preferable to moving data or invoking a service.
  2. Choose weak or strong mobility and specify exactly which data and execution state travel.
  3. Check architecture, runtime, library, identity, and resource compatibility at the destination.
  4. Authenticate the payload and grant only the capabilities needed for its declared task.
  5. Transfer, load, and start or resume under explicit failure and rollback rules.

Knowledge Transfer

Code mobility transfers across distributed runtimes when executable behavior itself crosses a boundary and runs at the destination. Shipping a machine-learning model, policy file, or query is code mobility only if the artifact has executable semantics in that system; passive data is not reclassified by metaphor. The more general place-computation-near-resources strategy can also be implemented without mobile code.

Neighborhood in Abstraction Space

Code Mobility sits in a moderately populated region (47th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Computer Systems & Network Architecture (20 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08