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.

The direction of movement distinguishes common styles. Remote evaluation sends code to a remote host for execution; code on demand downloads code to the requester; a mobile agent can decide or be instructed to migrate among hosts. All require a destination runtime that can reconstruct dependencies and an authority model that limits what arriving code can do. Moving only data to a fixed installed program is distributed computation, but not code mobility in this sense.

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.

Structural Signature

Sig role-phrases:

  • Executable unit — Identifies the program, object, script, or process image to move. It is required payload. Counterfactual: Moving only passive input data is ordinary distributed data transfer.
  • Origin and destination — Name distinct hosts, applications, or runtimes across which placement changes. It is required endpoints. Counterfactual: Relocation within an unchanged execution context may be scheduling rather than code mobility.
  • Transfer mechanism — Serializes, packages, authenticates, and transports the mobile unit and associated data. It is required operation. Counterfactual: Destination execution cannot occur if code identity or dependencies cannot be reconstructed.
  • Execution-state capture — Preserves control point, stack, bindings, and other runtime state for strong mobility. It is optional defining extension. Counterfactual: Without state capture, execution restarts and the mobility is weak.
  • Destination runtime — Loads, validates, links, and executes the received unit under compatible semantics. It is required environment. Counterfactual: Transported bytes are not mobile execution if the target cannot run them.
  • Authority and isolation policy — Controls what the arriving code may access and how provenance is evaluated. It is required security context. Counterfactual: Unbounded execution turns mobility into an uncontrolled trust transfer.

What It Is Not

  • Code mobility is not remote procedure invocation when the called code was already installed and only arguments cross the network.
  • It is not data migration or shipping a dataset to a stationary computation.
  • Copying source code for later manual installation is not the same as automatic destination execution.
  • Strong mobility is not guaranteed merely because code and heap data move; live control state must be preserved or reconstructed.
  • Closest near-miss. Process migration is a strong-mobility case when the live execution image moves; code on demand is weak mobility because the destination begins the downloaded code locally.

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.
  6. Measure whether relocation actually improves latency, bandwidth, resilience, or deployment cost without unacceptable risk.

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.

Examples

Canonical

A client downloads a signed script from a server, validates it in a sandbox, and starts it at a documented entry point with supplied data.

Mapped back: control → signature and sandbox; paradigm → code on demand; payload → code plus data; state → no suspended execution state.

Applied / In Practice

A mobile-agent runtime checkpoints an object's control state, transfers code, data, and checkpoint to another host, and resumes after reconstructing dependencies.

Mapped back: continuation → resume; mobility → strong; paradigm → mobile agent; payload → code, data, state.

Structural Tensions

T1 — Location Flexibility versus Environment Dependence. Moving computation toward resources can reduce communication, while architecture, libraries, and runtime state can prevent faithful execution.

Diagnostic: Which dependencies and semantics must travel or be standardized?

T2 — Extensibility versus Security Containment. Destination-loaded code enables adaptable systems but imports behavior across a trust boundary.

Diagnostic: What authentication, least authority, isolation, and revocation controls bound execution?

Structural–Framed Character

Code Mobility is structural with platform-framed realization. Payload, endpoints, state, transfer, and destination execution form a stable pattern. Serialization, compatibility, authority, licensing, and operational policy depend on a particular runtime and institution.

Structural Core vs. Domain Accent

The skeleton is relocation of an executable process between contexts. Distributed computing supplies hosts, network transport, runtime state, code provenance, sandboxing, and resource locality. Removing execution leaves ordinary object or data transfer.

  • Approved root. No reviewed parent currently entails executable behavior crossing a distributed-runtime boundary.

  • Related — migration, serialization, and capability. They support relocation but do not individually establish code mobility.

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

Not to Be Confused With

  • Remote procedure call. Tell: Moves requests and results while the service implementation remains installed at the server.
  • Data locality. Tell: Is an optimization objective that can be achieved by moving code, data, or both.
  • Virtual-machine migration. Tell: Can instantiate strong mobility when live machine state is transferred, but also includes infrastructure concerns beyond the general concept.
  • Software deployment. Tell: Installs or updates code, usually without preserving one running computation's state.

References

  • Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Code_mobility (revision 1151164058).
  • Preserved source candidate: http://www2.computer.org/portal/web/csdl/abs/trans/ts/1998/05/e0342abs.htm
  • Preserved source candidate: http://www.unsw.adfa.edu.au/~lpb/papers/mcode96.html
  • Preserved source candidate: https://web.archive.org/web/20120403045154/http://www.unsw.adfa.edu.au/~lpb/papers/mcode96.html

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.