Chapter Three- Processes

1. Introduction
A process is a program in execution.
OS manages processes (scheduling, memory, CPU).
In distributed systems, additional concerns:
Structuring clients and servers
Improving performance
Moving processes/code between machines (process migration)
Virtualization allows apps to run independently of hardware and OS. Benefits:
High portability
Failure isolation
Security enhancement

2. Threads
2.1 Introduction to Threads
A thread is a finer-grained unit of execution within a process.
Thread context ⊂ Process context ⊂ Processor context.
Threads share memory within a process but require careful programming for data
protection.
Benefits:
1. Better performance than single-threaded programs.
2. Parallel execution on multicore/multiprocessor systems.
3. Easier structuring of applications into independent tasks.

2.2 Threads vs Processes

Feature Process Thread

Memory Separate Shared
Protection OS/hardware Developer responsibility
Feature Process Thread
Context Switch Expensive Cheaper
Use Safety, isolation Performance, concurrency

2.3 Advantages of Threads

Avoid blocking entire program during I/O operations.
Exploit parallelism on multiple cores.
Simplify design of large applications.
Example: Spreadsheet program:
Thread 1 → user interaction
Thread 2 → recalculation of dependent cells
Thread 3 → backup to disk

2.4 Context Switching

Process context switch requires saving registers, changing memory maps, flushing TLB.
Thread context switch is lighter; mostly just CPU registers.
Cache perturbation can still impact performance.

2.5 Thread Implementation Models

1. User-level threads (Many-to-One)
Managed entirely in user space
Cheap creation/destruction and switching
Limitation: Blocking I/O blocks all threads in the process
2. Kernel-level threads (One-to-One)
OS schedules threads individually
Blocking I/O affects only the thread
Context switch more expensive
3. Hybrid threads (Many-to-Many)
Combines user and kernel threads
Each kernel thread may run multiple user threads
 Blocking I/O handled without affecting all threads
Example: Go language, libfibre, Arachne

2.6 Thread Use in Distributed Systems

Threads improve performance and parallelism in servers.
Threads can handle multiple tasks within one process efficiently.
Example: Apache Web server:
Uses processes for data isolation
Each process single-threaded, but multiple processes handle multiple requests

2.7 Key Notes

Threads are fast but require careful programming.
Processes are slower but safer due to hardware-enforced isolation.
Proper design is critical to avoid concurrency issues with threads.

3.1.2 Threads in Distributed Systems

Key Points:

Threads allow blocking system calls without blocking the entire process (except in many-
to-one threading models).
Useful for distributed systems where multiple logical connections run simultaneously.
Multithreading simplifies handling communication latency in wide-area networks.

Concept Explanation:

Distributed systems often face long message propagation delays. Threads let programs
initiate operations (like network requests) and continue doing other work while waiting.
Each thread can handle a separate task, making programming easier and improving
responsiveness.

Multithreaded Clients
Key Points:
 Hide network latency by doing tasks concurrently.
Example: Web browsers fetching HTML, images, and other resources in parallel using
multiple threads.
Threads allow standard blocking system calls without stopping the main application.
Multiple connections to replicated servers improve performance if threads can fetch data in
parallel.
Thread-Level Parallelism (TLP) measures how effectively threads use multicore processors.
Typical browsers had TLP of 1.5–2.5, meaning 2–3 cores needed for effective parallelism.

Concept Explanation:

Multithreading allows tasks like fetching images and rendering content simultaneously.
Threads simplify coding compared to manually handling asynchronous operations.
Even though browsers use hundreds of threads, parallelism depends on hardware and
software optimization.

Multithreaded Servers
Key Points:

Main benefit is server-side performance and parallelism.

Example: File server using dispatcher/worker model:
Dispatcher receives requests.
Idle worker threads process requests (can block on disk I/O).
Other threads continue processing new requests.
Alternatives:
1. Single-threaded server → simple but poor performance.
2. Finite-state machine → parallelism with nonblocking calls, but complex to program.

Concept Explanation:

Threads maintain sequential programming style while achieving parallelism.

Without threads, servers either waste CPU time (single-thread) or require complex
asynchronous code (FSM).
Using threads improves responsiveness and throughput for multiple client requests.

Server Model Summary (from Fig 3.7):

 Model Parallelism Blocking Calls
Multithreaded Yes Yes
Single-threaded No Yes
Finite-state machine Yes No

Additional Notes
Key Points:

Multiprocess servers can replace threads:

Pros: Better data isolation.
Cons: Communication overhead may reduce performance.

Concept Explanation:

Threads are lightweight and share memory, so they are faster for frequent communication
compared to multiple processes.

3.2.1 Principle of Virtualization

Key Points:

Virtualization extends or replaces an existing interface to mimic another system.

Initially introduced to run legacy software on mainframes (e.g., IBM 370) without
modifying it.
Modern virtualization supports:
Portability: Software can run on new hardware or platforms.
Flexibility: Multiple virtual environments on the same physical machine.
Isolation: Applications run independently, improving reliability and security.
Types of interfaces virtualized:
1. Instruction Set Architecture (ISA) – Privileged vs. general instructions.
2. System calls – OS-level services.
3. Library calls / APIs – Higher-level application interfaces.

Concept Explanation:
 Purpose: Virtualization separates software from hardware, allowing applications to run
independently of the underlying platform.
Portability: Legacy or platform-dependent software can be executed on new hardware
using virtual machines.
Isolation: Virtual machines protect other applications and the system from faults or security
issues.
Flexibility in distributed systems: Applications and their environments can run on the
same physical server, simplifying management and replication (e.g., content delivery
networks, edge servers).

Types of Virtualization:

1. Process Virtual Machine (for a single process)

Provides an abstract instruction set.
Instructions can be interpreted (e.g., Java) or emulated (e.g., running Windows apps
on Unix).
Virtualizes system calls and APIs for a single process.
2. Native Virtual Machine Monitor (VMM)
Runs directly on hardware and exposes the full instruction set.
Supports multiple guest operating systems concurrently.
Manages resources like CPU, memory, storage, and network.
3. Hosted Virtual Machine Monitor
Runs on top of a host operating system.
Leverages existing OS facilities like device drivers.
Requires special privileges but is simpler to implement.
Commonly used in data centers and cloud systems.

Performance Considerations:

Modern VMs run close to native performance, executing most instructions directly on
hardware.
Popek and Goldberg’s rules for efficient virtualization:
Sensitive instructions must be privileged.
Control-sensitive instructions affect hardware configuration.
Behavior-sensitive instructions depend on execution context.
 Some instruction sets (e.g., Intel x86) have non-privileged sensitive instructions.
Solutions:
1. Full emulation → slower performance.
2. Paravirtualization → modify guest OS to handle sensitive instructions correctly.

Takeaways:

Virtualization enables portability, isolation, and flexible resource management.

Essential for cloud computing and distributed systems.
Properly designed VMs achieve near-native performance while supporting multiple OS
environments on a single physical machine.

3.2.2 Containers
Key Points & Concepts

1. Purpose of Containers
Containers allow applications to run side-by-side while using their own software
environment (libraries, dependencies), without needing a full OS virtualization like
VMs.
Useful when the application’s instruction set and OS are stable, but libraries differ.
2. Container Composition
A container is a collection of binaries/images forming the software environment.
Includes directories with executables, libraries, documentation, etc.
Effectively virtualizes the software environment for the application.
3. Naive Implementation
Copy entire environment into a subdirectory (e.g., using chroot ).
Each application sees only its own environment.
Problems: inefficient, lacks proper isolation, no resource control.
4. Key Mechanisms in Linux/Unix
Namespaces: Gives processes in a container a private view of system identifiers (e.g.,
PID namespace, so each container sees its own init process as PID 1).
Union Filesystem: Layers file systems to share common files across containers, only
top layer writable. Efficient for using common OS versions or libraries.
Control Groups (cgroups): Limit resource usage per container (CPU, memory, etc.) to
prevent one container from starving others.
5. PlanetLab Example
Wide-area cluster using container-based virtualization before cloud popularity.
 VMM: Linux OS enhanced to support containers (Vservers).
Vservers: Containers in execution, strictly isolated, each with its own software
environment.
Slices: Group of Vservers across nodes forming a virtual cluster.
Resource Management:
Node Manager controls local resource allocation.
Slice Creation Service (SCS) creates Vservers based on authorized requests.
Resources allocated via rspec (time-based resource spec), uniquely identified by
rcap.
6. Advantages of Containers
Isolation: Processes in one container cannot see processes in another.
Resource efficiency: Dynamic allocation, overbooking possible (vs. fixed allocation in
VMs).
Simplified management: Easier to run tens of containers on a single node with limited
memory.
7. Modern Relevance
PlanetLab closed in 2020; similar systems like EdgeNet now use containers.
Containers remain key for cloud and edge computing environments.

3.2.3 Comparing Virtual Machines and Containers

1. Performance Debate

There’s ongoing debate about whether VMs or containers are better.

Terms like “lightweight containers” vs “heavyweight VMs” can be misleading.
Actual performance depends on workload, not just the label.

2. Performance Metrics

Important metrics: CPU, memory, disk I/O, network I/O.

Benchmarking depends on the workload; results vary with different scenarios.

3. Studies on Performance

Baseline comparison: Containers often perform slightly better than VMs, especially in I/O.
Traditional VMs are slower because the OS executes privileged instructions for I/O.
Recent studies: Differences between containers and VMs may be small due to OS
caching.
Application-level benchmarks (e.g., MySQL) show containers may be slightly faster, but it
depends on workload.
4. Resource Isolation

Running multiple applications side-by-side:

Containers can have difficulty isolating competing apps.
VMs manage CPU and disk resources better due to stronger isolation.
Overall: Overhead of virtualization has decreased over time, making performance close to
native.

3.2.4 Application of Virtual Machines to Distributed

Systems
1. Cloud Computing & Virtualization

Key role of virtualization: Lets cloud providers rent virtual machines instead of physical
hardware.
Provides almost complete isolation between customers.
Physical resources are shared, so absolute isolation is impossible, causing some
performance loss.

2. Amazon EC2 Example

Amazon Machine Images (AMIs): Preconfigured OS + software packages (e.g., LAMP

stack).
Launching an AMI creates an EC2 instance, a virtual machine running your applications.
EC2 hides the exact physical location of the instance.

3. EC2 Networking & Access

Each instance gets:

Private IP for internal communication
Public IP for external access via NAT
Access is usually via SSH keys generated in EC2.

4. Resource Management in EC2

Users can configure: CPU, memory, storage, architecture (32/64-bit), network bandwidth
Local storage is transient; data lost when instance stops
Persistent storage via:
S3: object storage
EBS: block storage, can be mounted to instances
5. Summary

IaaS (like EC2) lets users deploy networked virtual servers as a distributed system.
No need to maintain physical hardware.
Virtualization is fundamental to modern cloud computing

3.3 Clients – Simple Explanation

What is a client?

A client is basically a computer, phone, or device that asks a server for something.
Example: Your phone calendar asks a server to sync your events.

Two ways clients interact with servers:

1. Each app talks to the server on its own
Example: Calendar app talks to a calendar server.
The app handles communication itself.
2. Thin client (like a terminal)
The client is mostly a screen and keyboard.
Everything else (processing, saving files) is done on the server.
Example: Google Docs on a browser – your computer just shows what the server
sends.

Example: X Window System

X lets applications control what appears on your screen (windows, mouse, keyboard
input).
X kernel: The “brain” controlling the display hardware.
Xlib: A tool for apps to talk to X kernel.
Window manager: Special program that decides how windows look and behave.

Important idea:

Even though your apps are “clients,” the X kernel acts like a server, because it handles all
the requests from your apps.
Problems with thin clients over networks
Some apps ask the server many times in a row and wait for replies each time.
If the server is far away (long network distance), this slows everything down.

Solutions:

1. Optimize the messages: Only send what changed.

Example: Instead of sending a whole window, send just the part that changed.
2. Send the whole screen as pixels (like VNC):
Works for any app, but needs smart compression to avoid using too much internet.

✅ Key Takeaways
Clients ask servers for information.
Thin clients are mostly “dumb” – server does the work.
X system shows that clients can communicate with a display server.
Sending updates efficiently is important when clients and servers are far apart.

3.3.2 Virtual Desktop Environment

The idea: Instead of running all programs locally, your desktop can run in the cloud.
Your device just needs software to access it (like a browser).

Example:

Chrome OS uses the browser as the desktop interface. Apps may run in the cloud, but it
feels like they’re running locally.

How browsers work as virtual desktops:

1. Resource Loader: Downloads the HTML, CSS, scripts, images, etc.

2. DOM (Document Object Model): Represents the structure of the page.
3. Render Tree & Layout: Computes positions of elements, lines, images.
4. Painting & Rasterization: Converts elements into pixels on the screen.
5. Compositing: Combines layers into the final image you see.
6. Script Execution: JavaScript or WebAssembly runs client-side code to make the page
interactive.

Modern browsers split work across threads and processes, making it fast and secure.
Each browser tab has its own process, often in a sandbox to prevent attacks.
Key takeaway: Browsers can give the illusion that cloud apps are running locally — this is the
core idea of a virtual desktop.

3.3.3 Client-Side Software for Distribution Transparency

Clients do more than show a user interface. They can process data locally and help hide
the complexity of the server.

Types of transparency handled on the client side:

1. Access transparency: Client calls a server like it’s local; a stub converts calls into
messages to the server.
2. Location transparency: If the server moves, the client middleware can rebind
automatically.
3. Replication transparency: If there are multiple server copies, the client collects responses
and presents a single one.
4. Failure transparency: Middleware retries if the server fails or returns cached data.
5. Concurrency transparency: Managed more by intermediate servers, less by client
software.

Key idea: Client software helps make the system appear smooth and reliable, even if servers
are distributed, replicated, or failing.

✅ In short:
Virtual desktops make cloud apps look like they run locally.
Client software does both the UI and behind-the-scenes work to hide complexity in
distributed systems.

3.4 Servers
A server is a process that provides a service for clients. Its basic behavior:

1. Wait for a request from a client.

2. Handle the request.
3. Wait for the next request.
Key Design Considerations
1. Concurrent vs. Iterative Servers

Iterative server: Handles one request at a time. Only moves to the next request after
finishing the current one.
Concurrent server: Can handle multiple requests at the same time. Examples:
Multithreaded server: Spawns a thread for each request.
Forking server (Unix): Creates a new process for each request.

2. Client Contact: Endpoints

Clients connect to a server via an end point (port).

Well-known services: Fixed ports (e.g., HTTP → port 80, FTP → port 21).
Dynamic services: Port may change; a daemon can tell the client which port to use.
Superserver approach: One process (like inetd in Unix) listens to multiple ports and
launches a service when requested.

3. Interrupting a Server

Example: A client wants to cancel a large file upload.

Approaches:
Abruptly exit the client (not ideal).
Use out-of-band data: special data sent to interrupt the server.
In TCP, “urgent data” can interrupt normal flow.

4. Stateless vs. Stateful Servers

Stateless server: Does not remember client state after request.

Example: A standard Web server.
Advantages: Easier to recover after crash, simple design.
Can use soft state: keeps temporary info that expires after a while.
Stateful server: Keeps persistent info about clients.
Example: File server tracking which client has access to which file.
Advantages: Better performance for repeated operations.
Drawbacks: Server crash requires recovery of all client state.

Note on Web servers:

Stateless servers often use cookies to store client-specific info.

Cookies allow the server to “remember” users without being stateful itself.
3.4.2 Object Servers
Definition:
An object server does not provide a specific service directly. Instead, it hosts objects that
implement services. Clients interact with the objects to perform tasks.

Key points:

1. Objects
Each object has state (data) and methods (code).
Objects can be transient (exist temporarily) or persistent.
2. Invocation policies
The server decides how objects are invoked. Options include:
Single thread per object (serialized access).
Single thread per method (allows concurrency).
Thread pools for performance.
These policies are called activation policies.
3. Object adapters
Act as intermediaries between the server and objects.
Handle dispatching requests according to activation policies.
Can manage multiple objects with different policies simultaneously.
Work with skeletons (server-side stubs) to invoke object methods.
4. Dynamic object loading
Objects can be loaded into memory only when needed using locators.
Locators fetch object state dynamically (e.g., from a database).

Example: Ice Runtime System

Communicator: Manages resources like threads and memory.

Object Adapter: Created via the communicator, listens for requests, manages multiple
objects.
Objects are registered with the adapter, and clients use proxies to interact with them.

Summary: Object servers provide flexibility and modularity. They separate mechanism (how
objects are invoked) from policy (how activation happens), making it easier to manage
distributed objects.

3.4.3 Example: Apache Web Server

Overview:

Apache is a popular, highly configurable Web server.

Focuses on extensibility and platform independence using the Apache Portable
Runtime (APR).

Core concepts:

1. Modules:
Apache is modular; each module handles specific tasks (e.g., logging, URL translation,
access control).
Functions within modules respond to requests and return DECLINED if not relevant.
2. Hooks:
Mechanism to link functions to specific stages of request processing.
Ensures proper execution order and selective handling of requests.
Phases define when hooks are executed: beginning, middle, or end of request
processing.
3. Modular & stateless design:
Functions operate independently where possible.
This contributes to a modular, flexible, and maintainable design.

Summary:
Apache separates mechanism (runtime environment, request processing) from policy (how
requests are handled, which modules respond). Its design allows for extensibility and
modularity, supporting millions of Web requests efficiently.

✅ Takeaways from both object servers and Apache:

Separation of policy and mechanism is key for flexibility.
Concurrency and activation policies are critical design considerations.
Modular design makes systems extensible, maintainable, and scalable.

1. What is a server cluster?

A server cluster is a collection of machines connected through a network, each running
one or more servers.
Goal: Provide high availability, load distribution, and scalability.
Types:
1. Local-area clusters – connected by LAN with high bandwidth and low latency.
 2. Wide-area clusters – connected over the Internet (like cloud providers or CDNs).

2. Local-area server clusters

2.1 General organization
Typically organized in three tiers:
1. First tier – Logical switch / front-end: routes client requests.
2. Second tier – Application/compute servers: handle processing.
3. Third tier – Data servers: file servers, databases, high-speed storage.
Variations: Two-tier setups exist where each machine handles both applications and data
(common in media streaming).

2.2 Request dispatching

The switch is the entry point, offering a single network address to clients.
Types of switches:
1. Transport-layer switches: forward TCP connections, sit between client and server
(NAT style).
2. Application-layer switches: inspect request content (e.g., URL) to forward to the
proper server.
TCP handoff: a performance optimization where responses bypass the switch after initial
routing, reducing bottlenecks.

2.3 Load balancing

Round-robin: the switch forwards requests to the next server in a list.
Switch can also take decisions based on server load and request type.
Virtual machines can help migrate services to underutilized servers.

3. Wide-area server clusters

Distributed globally, typically run by cloud providers or CDNs.
Purpose: Provide locality (content close to clients) and high availability.
Example: Akamai CDN
Origin server: hosts original content.
Edge servers: cache content close to clients.
 Resolvers: decide the best edge server for a client.
Request redirection techniques:
1. TCP handoff: not suitable for wide-area networks.
2. DNS redirection: transparent to the client but may be inaccurate due to local DNS
servers.
3. HTTP redirection: nontransparent; the client sees the new URL.

4. Key observations
Server clusters hide complexity from clients (access transparency).
Switches and redirection mechanisms are central for load distribution and performance
optimization.
Wide-area clusters emphasize locality, scalability, and adaptive redirection to manage
global traffic efficiently.

3.5 Code Migration in Distributed Systems

1. Overview
Code migration: Moving programs (sometimes while executing) between machines.
Purpose: Simplifies design of distributed systems by executing code closer to data,
resources, or clients.

2. Reasons for Code Migration

2.1 Performance

Goal: Improve overall system performance by relocating processes or code.

Load balancing: Move from heavily loaded to lightly loaded machines.
Modern use: Migrate entire virtual machines for energy optimization and resource
consolidation.
Data proximity: Moving code to where the data resides reduces network traffic.
Example: Sending client application parts to a database server to process data locally.
Example: Executing form processing on the client to reduce small message
exchanges.

2.2 Parallelism
 Mobile agents can execute code across multiple sites to achieve linear speed-up.
Mobile agents historically failed to gain traction due to limited advantages over alternatives.

2.3 Privacy & Security

Example: Federated learning

Model is brought to local data, trained locally, then aggregated across multiple nodes.
Avoids sending sensitive data to a central server.
Iterative updates continue until the model is fully trained.
Easier with code migration than migrating full processes.

2.4 Flexibility

Dynamically move code to clients as needed (e.g., client-side scripts from the server).
Reduces the need to pre-install software on clients.
Supports evolving protocols and client-server interfaces without affecting clients.
Example: Web scripts or smartphone apps that can be updated dynamically.

3. Models for Code Migration

3.1 Process Components (Fuggetta et al., 1998)

Code segment: Instructions of the program.

Resource segment: References to external resources (files, devices, other processes).
Execution segment: Current execution state (stack, program counter, private data).

3.2 Migration Initiatives

Sender-initiated: Source machine initiates migration (e.g., uploading code to a server).

Receiver-initiated: Target machine initiates migration (e.g., Java applets).

3.3 Code Mobility Paradigms

1. Client-Server (CS): Code resides on the server; execution modifies server state.
2. Remote Evaluation (REV, sender-initiated): Client sends code to server; modifies server
state.
3. Code-on-Demand (CoD, receiver-initiated): Client downloads code; modifies client state
and resources.
4. Mobile Agents (MA, sender-initiated): Moves code and execution state; operates on
client and server resources.
4. Mobility Types
4.1 Weak Mobility

Only the code segment is moved.

Program always starts anew on the target.
Simple, portable (e.g., Java applets).
Does not preserve execution state from the source.

4.2 Strong Mobility

Execution state is also moved.

Process can resume execution exactly where it left off.
Hard to implement due to OS-dependent data in execution segments.
Techniques:
Process migration: Move a running process to a new machine.
Remote cloning: Fork a process and run the clone on another machine; original
continues in parallel.

4.3 Execution Context

Weak mobility can execute code in the target process space or a separate process.
In-process execution: avoids extra processes but risks running untrusted code.
Separate process: safer, isolates migrated code.

5. Summary
Code migration improves performance, privacy, flexibility, and parallelism in distributed
systems.
Can be implemented in various ways depending on who initiates migration, how much
state is moved, and where execution occurs.
Weak mobility is simple and portable; strong mobility offers full execution continuity but is
more complex.

3.5.3 Migration in Heterogeneous Systems

(Simplified Notes)
🔹 Main Idea
Moving code between machines is easy when all machines are the same (homogeneous).
But in real distributed systems, machines are different (heterogeneous):

different OS
different CPU architecture
different hardware

So migrated code may not run correctly on the new machine.

🔹 Problem
Heterogeneity makes code migration difficult because:

code compiled on one architecture (e.g., x86) may not run on another (e.g., ARM)
OS instructions differ
process state differs

This is the same problem as portability.

🔹 Early Solution (Pascal Example)

In the 1970s:

Pascal was compiled into machine-independent intermediate code

This code ran on a virtual machine implemented on each platform.

Idea:
👉 “Compile once, run anywhere as long as a virtual machine exists.”

🔹 Modern Solutions
Today the same idea is used by:

Java (JVM)
Python (interpreters)
Scripting languages

How it works:
 Java → compiler produces bytecode
JVM on each machine interprets that bytecode
→ So code can migrate and run anywhere.

🔹 Beyond Code: Migrating Full Environments

Instead of migrating just the program, now we migrate:

entire virtual machines (VMs)

OS + applications + memory + settings

This is done by:

Virtual Machine Monitors (VMMs) like VMware, Xen, KVM

Benefit:
👉 Processes are unaware of the migration. They continue running smoothly.

🔹 Challenges in VM Migration
1. Migrating memory
Three strategies:

(1) Push
Copy memory pages to the new machine
If pages change during copying → resend them

(2) Stop-and-copy
Stop the VM
Copy memory
Start VM on new machine
❗ Causes downtime (bad for live services)

(3) Pull/on-demand
Immediately start VM on new machine
 Load memory pages only when needed
❗ Very slow performance at beginning

🔹 Best Method → Pre-copy Migration (Clark et

al.)
Combination of:

Push (copy most pages while VM is running)

Short stop-and-copy (copy the last modified pages)

Result:
👉 Very low downtime (milliseconds to a few seconds)

🔹 Migrating resources
If migration stays inside one data center:

Network is the same → only update MAC address

Files are on shared storage → re-connect

If migration is across data centers:

Need to transfer files over WAN

Must ensure clients still reach the VM
Solutions include:
Network tunneling
Dynamic rebinding of IP addresses

🔹 Performance Issues
During migration:

Total migration time can be tens of seconds

Response time of services increases 10×–20×
During final cut-over → service unavailable for up to 4 seconds
🔹 VM Cloning
Used when:

Workload is too high

Need another VM quickly

Like fork() in Unix:

New VM starts almost fresh

Memory pages copied on demand

Result:
👉 Extremely fast cloning.

🔹 Summary
Migration in heterogeneous systems is solved by:

Language-based VMs (Java, Python)

Virtual machine migration
Techniques like pre-copy migration and VM cloning
Network tricks to keep connectivity