A cross-runtime taxonomy
of runtime data areas

Objective. This note compares storage organization across C++23, the Java Virtual Machine (JVMS, Java SE 25), and the Ethereum Virtual Machine (EVM). These systems expose different abstraction levels: C++ specifies object lifetimes and storage-duration categories; the JVM specifies run-time data areas for a managed abstract machine; and the EVM specifies consensus-critical execution state, persistent account storage, and gas-priced computation.

A comparative taxonomy, not a claim of equivalence

Method. The comparison projects specification-defined or documentation-defined constructs onto five analytical layers—executable representation, long-lived state, activation or operand state, runtime-allocated working data, and execution context or I/O—and evaluates each layer by purpose, lifetime, management authority, and cost model. Normative claims, implementation examples, and fork-dependent protocol facts are explicitly separated.

Contribution and limitation. The taxonomy is intended for teaching, review, and transfer of intuition between runtimes. It is not a formal semantics, a performance model, or a promise that similarly placed constructs are architecturally identical. Where the analogy leaks, the note states the leak rather than hiding it.

Contribution and limitation. The taxonomy is intended for explanation, review, and transfer of intuition between runtimes. It is not a formal semantics, performance model, or proof that similarly placed constructs have identical behavior. Where the analogy fails, the failure is stated explicitly in §8.

Keywords: runtime data areas; storage duration; managed runtime; JVM; EVM; persistent state; comparative systems pedagogy.

§1 · Motivation

Three specification layers for “a running program”

• C++ specifies an abstract machine, object lifetimes, and four storage-duration categories. Conventional implementations map these semantics onto an operating-system process, ABI, loader, registers, stacks, and dynamically allocated regions; those concrete regions are not mandated by the language standard [1].
• JVM specifies a managed abstract machine with shared and per-thread run-time data areas. HotSpot details such as Metaspace and a code cache are implementation choices layered beneath the JVMS abstraction [2].
• EVM specifies consensus-critical execution. Each execution frame has stack, memory, code, and input/output context, while contract storage contributes to persistent protocol state; gas makes resource use explicit and fork-dependent [5].

The systems therefore cannot be compared by names alone. “Stack,” “memory,” “static,” and “storage” denote different mechanisms. A useful comparison must ask the same questions at each level: what a region is for, how long its contents survive, who manages it, and what costs or constraints govern it.

§2 · The framework

The five-layer lens

For comparative purposes, the note projects each runtime onto five analytical layers and reads each layer along four axes: purpose (what it represents), lifetime (frame, thread, process/VM, transaction, or cross-transaction), management (language, runtime, programmer, or protocol), and cost (machine resources, runtime overhead, or gas). These layers are categories of analysis, not claims that the underlying mechanisms are interchangeable.

§3 · C++23

Language-level storage duration and common process realizations

The C++ standard specifies object lifetime and storage duration, not a required process layout. It distinguishes static, thread, automatic, and dynamic storage duration [1]. Text, data, BSS, TLS, call stacks, registers, and allocator “heaps” are conventional ABI and operating-system realizations of those semantics.

storage_duration.cpp

int a = 10;        // static storage duration; commonly writable data
int b;             // static duration; zero-initialization is guaranteed
int c = 0;         // static duration; commonly placed with zero-initialized data
const int D = 42;  // static duration; may be read-only or require no storage
static int e = 5;  // static duration with internal linkage
thread_local int t;// thread storage duration; commonly thread-local storage

int main() {
    int x = 20;            // automatic duration; often a register or stack slot
    int* p = new int(99);  // p: automatic duration; *p: dynamic storage duration
    delete p;              // ends the allocated object's lifetime and releases storage
}

What is distinctive

• Native machine code is the dominant implementation strategy, but the language is specified by an abstract machine rather than a particular executable-file format.
• Automatic and member-object lifetimes support deterministic destruction; RAII and ownership types can manage resources without explicit delete at each use site.
• Dynamic storage is managed explicitly or through libraries such as smart pointers and containers; the standard does not require a tracing garbage collector.
• Raw pointers and pointer arithmetic expose low-level addressing with correspondingly strong safety obligations.
• Undefined behavior permits optimizations that assume prohibited executions do not occur.

§4 · JVM, Java SE 25

Specification-level run-time data areas and implementation choices

The JVMS defines logical run-time data areas independently of any particular operating-system layout. Some are shared by all threads and live for the JVM instance; others are created per thread. The core areas are the pc register, JVM stacks, heap, method area, run-time constant pools, and native method stacks [2].

Student.java

class Student {
    static int count = 0;  // class-associated state; physical placement is JVM-specific
    String name;           // instance field stored as part of a heap object

    void enroll(String course) {
        int credits = 3;           // logical local-variable slot in this frame
        count++;                   // getstatic / putstatic at the bytecode level
        Student s = new Student(); // reference local; object normally allocated on heap
    }
}
// A JIT may keep locals in registers and may eliminate allocations
// when those optimizations preserve Java's observable behavior.

What is distinctive

• Class files contain bytecode and symbolic metadata; a JVM may interpret, compile, or mix execution strategies.
• Garbage collectors reclaim unreachable heap objects according to implementation policy; collection timing is not a prompt-destruction guarantee.
• References do not support language-level pointer arithmetic, and array accesses are checked.
• JVMS frames are logical structures. A JIT may represent their values in registers or optimized metadata rather than literal native stack slots.
• Class-file portability is subject to supported class-file versions and to platform-specific native libraries or external resources.

§5 · EVM

Consensus-critical frame state and persistent contract state

The EVM is a deterministic state-transition machine executed by Ethereum clients. Each execution frame has code, an operand stack, linear memory, input data, return data, gas, and environmental context; persistent account storage contributes to protocol state. All consensus implementations must reproduce the same valid transition under the active fork rules [5].

Counter.sol

contract Counter {
    uint256 public count;                     // persistent storage; mutable across txs
    event Incremented(uint256 value);

    function increment(uint256 amount) external {
        // amount is encoded in calldata and loaded as required
        uint256 next = count + amount;        // usually stack-resident; compiler-dependent
        count = next;                         // SSTORE under active fork gas rules

        uint256[] memory buf = new uint256[](3); // frame-local linear memory
        buf[0] = next;                        // discarded with this external call frame

        emit Incremented(next);               // log entry in the transaction receipt
    }
}

What is distinctive

• Execution is consensus-critical: valid clients must agree on the resulting state, logs, return data, and gas accounting.
• Persistent storage is word-keyed contract state; its writes are substantially more expensive than stack or memory operations, with exact costs determined by the active fork.
• Transient storage introduced by EIP-1153 is address-scoped, transaction-lifetime key-value state. It can be observed across relevant call frames during one transaction, participates in revert semantics, and is cleared at transaction end [6].
• Solidity's storage, memory, and calldata annotations describe source-level data locations for reference types; raw EVM execution manipulates stack words, byte offsets, and storage keys [7].

§6 · Side by side

Unified comparison with abstraction levels preserved

Axes that differ most

§7 · The same source-level idea, three runtimes

A long-lived counter and temporary working data

The examples express the same source-level intent, but their lifetimes are not equivalent: the C++ and Java counters are bounded by a process or class lifetime, whereas the Solidity counter survives across transactions in protocol state.

int counter = 0;   // static duration; commonly writable data
int resetTo;       // static duration; zero-initialized by the language

void add(int amount) {            // ABI may use registers and/or stack
    int next = counter + amount;  // automatic duration; placement may be optimized
    counter = next;
}
int* makeBuffer(int n) {
    return new int[n];            // dynamic storage; caller must establish ownership
}

class Counter {
    static int counter = 0; // class variable; physical placement is JVM-specific
    static int resetTo;     // default-initialized to zero

    static void add(int amount) {
        int next = counter + amount; // logical frame local; JIT placement may differ
        counter = next;
    }
    static int[] makeBuffer(int n) {
        return new int[n];           // heap object; reclaimed when unreachable
    }
}

contract Counter {
    uint256 public counter; // persistent storage across transactions
    uint256 public resetTo; // another persistent storage slot, default zero

    function add(uint256 amount) external {
        uint256 next = counter + amount; // compiler typically uses stack, may spill
        counter = next;                  // persistent state update
    }
    function makeBuffer(uint256 n) internal pure returns (uint256[] memory) {
        return new uint256[](n);         // current EVM frame's linear memory
    }
}

Placement summary

§8 · Limits of the analogy

Where the taxonomy leaks

The taxonomy is useful precisely when its limits are visible. Similar purpose does not imply similar lifetime, representation, observability, failure mode, or cost.

Name clashes — the same word denotes different mechanisms

Structural mismatches

• EVM memory belongs in the runtime-allocated layer only by analogy: it is a linear arena with no object graph and no per-object freeing.
• Calldata, returndata, and logs are I/O channels rather than memory regions in the same sense as a heap or stack; they are grouped with execution context for comparative convenience.
• Transient storage is transaction-scoped state, not frame-local working memory. It is shared across relevant frames and follows revert semantics.
• C++ “segments” and HotSpot Metaspace are implementation categories; treating them as normative language/JVMS constructs would mix abstraction levels.

§9 · Terminology

Why this is called a data-area taxonomy

“Memory model” is overloaded in standards literature. C++ uses the term for foundational notions such as bytes and memory locations and separately specifies multithreaded executions and data races; Java's Memory Model specifies inter-thread visibility, ordering, and happens-before relations [3]. Neither meaning is the subject of this note.

This document instead concerns storage duration, run-time data areas, execution-frame state, and persistent protocol state. “Runtime data-area taxonomy” is therefore the least ambiguous label.

§10 · Quick reference

One precise sentence each

§11 · Beyond three

Extending the taxonomy cautiously

For another runtime, ask which constructs serve each analytical purpose, then record where the mapping fails.

The lens is a lens, not a law. Some runtimes blur the boundaries (for example, CPython frame objects are heap allocated); others add dimensions such as explicit I/O channels. Use the taxonomy to formulate questions, then verify every claim against the relevant specification and implementation.

§12 · Final checks

Accuracy checklist for readers

The final edition intentionally marks the claims most likely to be mistaught. Use this list when reviewing slides, exam answers, or implementations derived from the taxonomy.

§13 · Primary sources

References

1. ISO/IEC. ISO/IEC 14882:2024, Programming Languages — C++. Publicly accessible working draft: Thomas Köppe, ed., Working Draft, Standard for Programming Language C++, WG21 N4950, 10 May 2023, especially §6.7.5 “Storage duration,” §6.7.1 “Memory model,” and §6.9.2 “Multi-threaded executions and data races.” WG21 N4950.
2. Lindholm, T.; Yellin, F.; Bracha, G.; Buckley, A.; Smith, D. The Java Virtual Machine Specification, Java SE 25 Edition. 29 July 2025, §2.5 “Run-Time Data Areas” and §2.6 “Frames.” Oracle JVMS 25.
3. Gosling, J.; Joy, B.; Steele, G.; Bracha, G.; Buckley, A.; Smith, D. The Java Language Specification, Java SE 25 Edition. §17.4 “Memory Model.” Oracle JLS 25.
4. Masamitsu, J. “JEP 122: Remove the Permanent Generation.” OpenJDK, delivered in JDK 8. Establishes the HotSpot implementation change that removed PermGen and moved class metadata to native memory; the final note treats Metaspace as implementation vocabulary, not a JVMS data-area name. OpenJDK JEP 122.
5. Ethereum Foundation. “Ethereum Virtual Machine (EVM).” Describes deterministic state transition, 1024-entry 256-bit stack, memory, persistent storage, transient storage, and gas. ethereum.org EVM documentation. Consensus-sensitive details should be checked against the current Ethereum Execution Layer Specifications.
6. Akhunov, A.; Salem, M. “EIP-1153: Transient Storage Opcodes.” Final Core EIP. Specifies transaction-scoped TLOAD/TSTORE, frame sharing, revert behavior, and clearing at transaction end. EIP-1153.
7. Solidity Project. “Transient Storage in Solidity 0.8.24.” Explains Solidity compiler support for EIP-1153 and notes that transient storage is scoped to the current transaction and reset afterward. Solidity blog — transient storage.
8. Solidity Project. “Types — Data location,” “Layout in Memory,” and “Layout of State Variables in Storage and Transient Storage.” Data locations; memory layout; storage layout.
9. Ethereum Improvement Proposals. “EIP-7569: Hardfork Meta — Dencun.” Lists EIP-1153 among the execution-layer changes activated in the March 2024 Dencun network upgrade. EIP-7569.

Accessed: 26 June 2026. Version-sensitive statements are labeled as specification-level, implementation-specific, or fork-dependent. For legal or production-critical work, consult the cited specifications and the implementation or fork actually in use.