← Back to Midterms
Activity 1

Variables & Memory Analysis

★ 27 / 30 | ➤ March 2, 2026

Explanation & Learnings

In this activity, the main focus was to analyze a Java program — included in Part C — to identify the variables used, its data types, and where they are stored in memory. I also provided explanation on how the logic works; specifically, tracing object references and memory changes.

Part A: Variable Identification Table

Variable Name Data Type Variable Type Stored in
name String instance heap
grade int instance heap
n String local stack
g int local stack
s1 Student reference stack
s2 Student reference stack
s3 Student reference stack

Java was a lot more complicated than I thought compared to other languages I learned like C or Python. But they were all just the same in having to understand how memory is allocated and managed across the program's lifecycle. Variable types like instance is stored in the heap, while local and reference variables are both in stack. One of the most fulfilling aspects of this activity was realizing that I can determine the output even if I haven't ran the program.

Part B: Explanation

Statement What Happens? Memory Impact
Student s1 = new Student("John", 85); Variable Student sets the name to "John" and the grade to "85". A Student object is created in the Heap. s1 in the stack stores the memory address.
Student s2 = new Student("Maria", 90); Variable Student sets the name to "Maria" and the grade to "90". A Student object is created in the Heap. s2 in the stack stores the memory address.
Student s3 = s2; The reference address on s2 is copied to s3. Both s2 and s3 now point to the exact same object in the Heap ("Maria", 90).
s1.grade = 95; Overwrites the grade assigned in s1 (85), thus resulting in 95. The value in first object's grade field in the Heap changes from 85 to 95.
s3.name = "Ana"; Overwrites the name assigned in s3 (Maria), thus resulting in "Ana". Because s3 and s2 point to the same object, changing s3.name also changed s2.name. The object in the heap has the name "Ana" now.

Creating this explanation table really helped me to understand object references better. It's fascinating how multiple variables can point to the exact same object in the heap. Seeing that changing s3.name also changed s2.name due to overwriting s3 reference variable was just like how pointers work in C. It proved that they aren't independent copies, but rather shared references.

Part C: TestStudent.java

TestStudent.java 
class Student {
    String name;
    int grade;
    Student(String n, int g) {
        name = n;
        grade = g;
    }
}

public class TestStudent {
    public static void main(String[] args) {
        Student s1 = new Student("John", 85);
        Student s2 = new Student("Maria", 90);
        Student s3 = s2; // Reference copy

        s1.grade = 95;
        s3.name = "Ana";

        System.out.println(s1.name + " " + s1.grade);
        System.out.println(s2.name + " " + s2.grade);
        System.out.println(s3.name + " " + s3.grade);
    }
}
Terminal 
John 95
Ana 90
Ana 90

Finally, reviewing the actual code and terminal output confirmed my manual trace. It was incredibly satisfying to see the terminal print out exactly what I had predicted in my analysis. This practical verification gave me a lot of confidence in my ability to trace memory allocation and variable states without relying entirely on the compiler to tell me what happens.

Attached Resources

DeOro_CodeAnalysis#1.pdf Trace Table