Stack-Edu: Novice Programming Visualizer

• Stack-Edu is a novice-oriented visualization tool that clearly distinguishes stack, heap, and global/static memory to aid in understanding program execution.
• It employs debugger-driven JSON snapshots to couple source lines with runtime state changes, making execution dynamics explicit.
• The tool addresses educational challenges by reducing cognitive load with intuitive displays and backward navigation features.

Stack-Edu—Editor’s term for the novice-oriented stack/heap visualization approach described in “A tool for visualizing the execution of programs and stack traces especially suited for novice programmers”—is an IDE-integrated program-execution visualizer for Java and C/C++ that makes runtime state explicit through separated views of stack, heap, and, for C/C++, global/static memory (Litvinov et al., 2017). It is motivated by persistent difficulties in introductory programming education, especially learners’ problems in treating programs as dynamic processes, understanding instruction execution and memory management, and reasoning about control flow, calls, returns, pointers, and references. The system’s central design decision is to make the stack trace the main element of visualization, while coupling source lines to runtime state through debugger-driven snapshots serialized in a common JSON format.

1. Educational problem setting and conceptual motivation

The work is situated in software engineering education, where introductory programming courses are reported to have high failure rates of approximately 33% (Litvinov et al., 2017). The paper associates early difficulty with runtime behavior and memory organization with reduced motivation to continue in programming studies. The obstacles identified are not primarily syntactic. They concern the semantics of execution: understanding a program as an evolving process rather than static source text, understanding how a computer executes instructions, and making implicit constructs such as pointers and references visible enough for analysis.

A central misconception addressed by the visualization concerns the distinction between stack and heap. The stack is presented as the location of activation records for parameters and local variables, with deterministic size characteristics, whereas the heap is used for dynamic allocation and includes metadata overhead. The paper further emphasizes that only data of known, fixed size at compile time fits the stack, while runtime-sized data reside on the heap. For novices, this distinction is often obscured by source-language abstractions, especially in Java, where references and garbage collection hide many operational details.

The paper also argues that standard debuggers are insufficient for beginners. Conventional debuggers presume familiarity with memory organization, provide limited pedagogical scaffolding, and do not typically explain state changes or provide novice-oriented cues. This suggests that the tool is not intended to replace debugging infrastructure, but to reframe it pedagogically by exposing execution state in a form aligned with conceptual learning rather than expert troubleshooting.

2. Prior tools and the gaps Stack-Edu addresses

The paper surveys a broad range of existing visualization and debugging tools for Java and C/C++, including DYVISE, JIVE, Trace, EXTRAVIS, Memview, CoffeeDregs, JaVis, JAVAVIS, EVizor, JavaTool, Labster, Project S, a web-based tutor for C++ memory layout, VIP, Bradman, Teaching Machine, and jGRASP (Litvinov et al., 2017). Across these systems, the authors identify several recurring strengths: stepping support, including forward and sometimes backward navigation; timeline views; search mechanisms; multithreading or deadlock visualization in some environments; and textual explanations in a subset of tools such as EVizor and Bradman.

The review is nonetheless structured around educational shortcomings. Only a few tools clearly separate stack and heap in the visualization. Many are considered inconvenient for beginners because of cognitive overload or advanced user interfaces. Some do not integrate smoothly with mainstream IDEs, especially Eclipse. Others do not permit arbitrary user code, or remain research prototypes with limited deployment beyond the institutions that produced them.

Within that comparative frame, the proposed system is differentiated by four claims. First, it provides explicit side-by-side separation of stack and heap, and, for C/C++, a distinct global/static region. Second, it uses beginner-focused filtering by hiding system or internal objects and showing only objects referenced by user variables. Third, it works on user code in mainstream IDEs—Eclipse for Java and C/C++, and IntelliJ IDEA for Java. Fourth, it supports backward navigation through time-stamped JSON snapshots, rather than requiring a specialized reverse debugger.

These differences are design-based rather than empirically validated. The paper does not report measured learning gains or comparative benchmarks against earlier systems, so its differentiation remains architectural and pedagogical rather than quantitative.

3. System architecture, debugger interfaces, and snapshot model

The prototypes are implemented as IDE plugins: for Java, plugins for Eclipse and IntelliJ IDEA; for C/C++, an Eclipse plugin (Litvinov et al., 2017). Runtime state is obtained through standard debugger interfaces. On the Java side, the system uses the Java Debugging Interface (JDI), which provides access to threads, virtual-machine state, classes, arrays, interfaces, and primitive types. On the C/C++ side, it uses Eclipse’s C/C++ Debugging Interface (CDI), which interacts with Eclipse CDT and may use external debuggers such as GDB.

The architecture is event-driven. The IDE plugin listens for execution events corresponding to changes in process or thread state. At each step, it queries JDI or CDI and assembles a JSON snapshot. The snapshot includes the programming language, thread information for Java, the stack, the heap, the current source line via a lineNumber field, and, in C/C++, a globalStaticVariables block. Stack frames store function or method names, arguments, and local variables. Heap entries store objects or allocations with types and values. Variable entries include name, type, and value, as well as an address in C/C++ or an identifier for Java objects.

The JSON files are time-stamped and saved sequentially. The visualization subsystem then consumes those snapshots to render the current state and prior states. This common JSON model is explicitly described as IDE-independent and language-unified. A plausible implication is that the authors treat the debugger-specific extraction logic as the only platform-dependent component, while the visualization layer is intended to scale across languages and development environments through the shared intermediate representation.

The paper does not formalize this model with an operational semantics or LaTeX-state transition system. Execution is instead described informally through the snapshot schema and the stack/heap decomposition. It also does not present complexity analysis or measured runtime overhead, although the architecture makes clear that cost is driven by debugger event frequency and JSON serialization.

4. Visualization model and representation of runtime state

The visualization is organized around a clear memory model with separate regions for stack, heap, and, in C/C++, global/static memory (Litvinov et al., 2017). The stack is the primary visual anchor. Each call stack frame corresponds to an activation record and displays the function or method name, parameters, and local variables. When a call occurs, a new frame appears at the top; when a return occurs, the frame is removed through ordinary stack unwinding. To reduce clutter, the most recent frame can be auto-expanded while older frames can be collapsed.

Heap visualization differs by language. In Java, the system shows objects referenced from the stack, displaying each object’s type, fields, and object identifier. In C/C++, it shows heap allocations with types, values, and memory addresses. Aliasing is made explicit through cross-referencing names and addresses; the heap table includes a “name” field so that stack references or pointers can be matched to heap entries. For C/C++, a separate block lists global and static variables together with type, value, and address.

The paper emphasizes several cognitive-load reductions. The layout uses a vertical growth model in which the newest frame or object appears at the top, with prior states below. The current execution line is highlighted in the source editor, the last modified or created variables and objects are highlighted in the visualization, and only user-relevant heap objects are shown. This selective visibility is particularly important in Java, where the visualization focuses on live, user-referenced objects rather than the full managed heap.

The model also encodes language differences. Java snapshots treat threads as first-class debugger entities and include per-thread stack information, while the visualization of multithreading itself is not yet implemented. C/C++ emphasizes manual memory management, visible pointer addresses, and explicit segmentation of stack, heap, and global/static storage. The paper notes that exception propagation and stack unwinding could in principle be shown through standard debugger events, but the prototype focuses on normal stepping.

5. Interaction design and IDE workflow

The system is embedded in the standard debugger workflow of the host IDEs, rather than introducing a separate execution environment (Litvinov et al., 2017). Users can set breakpoints, run to a breakpoint, and invoke standard debugger commands such as step into, step over, and step return. The current execution line is highlighted directly in the editor, preserving a tight source-to-state mapping.

A significant feature is backward navigation. Rather than implementing reverse execution at the debugger level, the system replays stored snapshots, allowing users to select earlier JSON states and step back conceptually through the execution history. This gives beginners access to temporal inspection without requiring low-level reverse-debugging mechanisms.

The user interface includes collapsible blocks for the heap, stack, global/static memory, and individual stack frames. Older frames may be auto-minimized so that the focus remains on the current context. Newly created or recently changed variables and objects are highlighted. The display is explicitly tabular, showing type, name, and value, and additionally addresses or object identifiers when relevant.

These choices are pedagogically targeted. The paper’s stated aim is not maximal debugger expressiveness, but a constrained representation that exposes the semantics novices most often miss: frame creation and removal, object allocation and mutation, reference or pointer relationships, and the correspondence between a highlighted source line and the resulting state transition.

6. Illustrative execution scenario, limitations, and prospective development

The paper includes a Java example centered on a Sample class whose main method creates a Demo object, mutates its fields, and defines local variables a, b, and s (Litvinov et al., 2017). At program start, the stack shows a main frame with parameter args, while the heap is empty. After Demo obj = new Demo();, a new Demo object appears in the heap with default fields and an identifier, and the local variable obj in the stack stores a reference to that object. After obj.i = 70; and obj.c = 'Z';, the object’s fields are updated and highlighted. After int a = 5; int b = obj.i; String s = "Hello";, the stack contains locals a=5, b=70, and s="Hello", while the heap shows the Demo object and, if visible through user reference, the String "Hello" object. When execution returns from main, the frame is popped, and objects no longer referenced by the stack may disappear from the visualization.

No C/C++ code example is provided in the paper. The description of C/C++ behavior is therefore schematic: addresses would be shown for stack and heap variables, a global/static region would be present, and dynamic allocation through new/delete or malloc/free would appear in the heap with explicit addresses, with deallocation reflected by removal or marking of entries. Because the paper itself presents this as a projection of the visualization model rather than a documented walkthrough, such details are better read as design intent than as demonstrated case-study behavior.

The limitations are explicit. The system is still at the prototype stage. Multithreading visualization is not implemented, even though Java snapshots already capture thread status and stack contents. Textual explanations, which the authors regard as useful in prior tools, are absent from the current prototypes. No empirical user study, participant data, task design, quantitative learning outcomes, or performance measurements are reported. The paper instead presents the prototypes as a basis for future development.

Planned extensions include a timeline rendered as a sequence diagram for multithreading and time-based events, and textual tips or explanations aligned with the current source line. The prototype source code is available in a public repository, and the authors state their intention to release the tool under an Open Source license. In that sense, Stack-Edu is best understood not as a completed educational platform with validated outcomes, but as a concrete architecture for novice-oriented execution visualization: one that prioritizes clarity, explicit memory segmentation, source-state coupling, and snapshot-based temporal navigation in Java and C/C++ environments.