Where does data actually live?

Method: classify storage by role before applying runtime vocabulary.

The same noun can mislead. “Memory” in Solidity, “heap” in the JVM, and “dynamic storage duration” in C++ are not interchangeable. A more reliable method first asks what a storage area is for, how long it can live, who controls its reclamation, and what resource makes it costly.

A five-layer map across three runtimes.

Hover, focus, or tap a layer to highlight the corresponding conceptual region in C++, the JVM, and the EVM. The point is not that these systems are implemented the same way; the point is that they answer comparable storage questions.

Three runtimes, three kinds of control.

C++: storage duration in a native implementation

At the language level, C++ classifies storage by duration: automatic, static, thread, and dynamic. Those categories describe the minimum potential lifetime of the storage that contains an object. A particular compiler, operating system, loader, and ABI may realize those categories through familiar regions such as executable text, read-only data, initialized data, BSS, thread-local storage, native call stacks, and allocator-managed free-store or heap regions. These implementation names are pedagogically useful, but they should not be confused with the formal language taxonomy.

JVM: specified run-time data areas with implementation freedom

The JVM Specification defines run-time data areas used during program execution. Some are created when the JVM starts and destroyed when it exits; others are per-thread and are created and destroyed with the thread. The specification names the pc register, JVM stacks, heap, method area, run-time constant pool, and native method stacks. Object allocation occurs from the heap, while frames on JVM stacks contain local variables, operand stacks, dynamic linking information, and return state. Garbage collectors, JIT compilers, Metaspace, and code caches are implementation mechanisms layered beneath or beside the abstract specification.

EVM: deterministic state transition under gas

The EVM is a deterministic stack machine whose execution must be reproducible by network participants. It operates on a bounded stack of 256-bit words, uses transient linear memory during message-call execution, reads call input from calldata, and writes durable contract state through storage slots. EIP-1153 adds transient storage: a transaction-scoped key-value store accessed with TLOAD and TSTORE and cleared at the end of the transaction. Gas makes computation, memory expansion, and state access explicit economic costs rather than hidden implementation overheads.

The unified comparison table.

This table compresses the taxonomy into a quick lookup. Treat it as a concept map, not a promise that every implementation names or lays out memory exactly this way.

Lifetime spectrum

One counter, three storage stories.

A counter looks trivial, but it reveals the deepest runtime difference: native process state, managed VM state, and blockchain state do not have the same lifetime.

// C++: static storage lasts for the duration of the program.
static int counter = 0;

int increment() {
    int local = ++counter;  // local: automatic storage
    return local;
}

// Java: static class state is associated with class loading and VM behavior.
final class Counter {
    private static int counter = 0;

    static int increment() {
        int local = ++counter; // local: JVM frame
        return local;
    }
}

// Solidity: state can persist across transactions.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Counter {
    uint256 public counter; // storage slot

    function increment() external returns (uint256) {
        counter += 1;
        uint256 local = counter; // stack / memory depending on compilation
        return local;
    }
}

Where the lens leaks.

A good taxonomy should show its own edges. These are the places where the five-layer map is useful but not exact.

One sentence per runtime.

Exam-safe mnemonic

References

• [C++ storage duration]C++ distinguishes static, thread, automatic, and dynamic storage duration. Implementation segment names such as text, data, BSS, and heap are useful but non-normative vocabulary. Accessible reference: cppreference — storage duration.
• [JVMS SE 25 §2.5]The Java Virtual Machine Specification defines run-time data areas including the pc register, JVM stacks, heap, method area, run-time constant pool, and native method stacks. Oracle JVMS §2.5.
• [Solidity data locations]Solidity documents storage, memory, and calldata as data locations for reference types; calldata is non-modifiable and non-persistent. Solidity docs — data location.
• [Solidity storage layout]Solidity specifies storage and transient-storage layout rules; the layouts are independent, and only value types are supported for transient storage. Solidity docs — storage and transient-storage layout.
• [Solidity memory layout]Solidity memory uses a free-memory pointer, places new objects at that pointer, and does not free memory during execution under the current model. Solidity docs — memory layout.
• [Ethereum EVM overview]Ethereum’s developer documentation describes the EVM as a stack machine with 1024 stack items, each a 256-bit word, and distinguishes memory, storage, transient storage, and gas-priced execution. ethereum.org — EVM.
• [EIP-1153]EIP-1153 defines the TLOAD and TSTORE opcodes and specifies that transient-storage values are discarded at the end of the transaction. EIP-1153.
• [Ethereum execution specifications]The Ethereum Execution Layer Specifications provide an executable Python reference implementation and tests for execution-layer behavior. Ethereum execution-specs.