DEV Community: S M Tahosin

Your CPU Never Executes Java. The JVM Rewrites It at Runtime.

S M Tahosin — Tue, 29 Sep 2026 13:09:39 +0000

You write System.out.println("Hello World"); and hit Run.

Something happens. Text appears on your screen. You smile. You move on.

But have you ever stopped and asked yourself... what actually happened between you pressing Run and that text showing up? Because I promise you, there is a ridiculous amount of machinery working behind the scenes. And understanding that machinery is the difference between a coder who writes Java and a developer who truly gets Java.

I spent two weeks going through the OpenJDK source code, reading JVM specifications, running bytecode experiments, and breaking things on purpose. What I found was fascinating, and today I want to walk you through all of it. No boring textbook stuff. Just real, practical, "oh wait, THAT is what is happening?" kind of learning.

Let's open the hood on the Java Virtual Machine.

Wait, Java Does NOT Run Your Code Directly?

Here is the first thing that surprises most beginners. When you write Java code and click Run, the Java compiler does NOT turn your code into machine code. Not directly, anyway.

Instead, the javac compiler converts your .java file into something called bytecode, stored in a .class file. This bytecode is a set of instructions that no physical computer on Earth can execute directly.

So who runs it?

The JVM (Java Virtual Machine). It is a virtual computer that lives inside your real computer. It reads the bytecode, understands it, and figures out how to run it on whatever machine you are using. Windows, Mac, Linux... the JVM handles the translation.

This is why Java's famous tagline is "Write Once, Run Anywhere."

Your Code (.java)
       |
       v
  javac compiler
       |
       v
  Bytecode (.class)
       |
       v
  JVM interprets/compiles
       |
       v
  Your CPU executes it

Think of it like this. You write a letter in English. A translator (javac) converts it into a universal language (bytecode). Then a local interpreter (JVM) reads that universal language and speaks it in whatever local language (machine code) your computer understands.

The Three Pillars Inside the JVM

The JVM is not just one thing. It is made up of three major components working together:

1. The Class Loader

Before your code can run, the JVM needs to load it into memory. That is the Class Loader's job.

It works in three phases:

Loading: Finds the .class file and reads the bytecode
Linking: Verifies the bytecode is valid (no hacks!), allocates memory for static variables, and resolves symbolic references
Initialization: Runs static blocks and assigns values to static variables

Here is something cool. The Class Loader does not load ALL your classes at startup. It loads them on demand, only when your code actually uses them. This is called lazy loading, and it keeps your program starting up fast.

// This class is NOT loaded until this line actually executes
MyHeavyClass obj = new MyHeavyClass();

// If this line is inside an if-block that never runs,
// the class never gets loaded at all!

2. Runtime Data Areas (Stack and Heap)

This is where your program's data actually lives during execution. The JVM divides memory into several areas, but the two big ones you need to understand are the Stack and the Heap.

3. The Execution Engine

This is the brain that actually runs your bytecode. It has an Interpreter, a JIT Compiler, and a Garbage Collector. We will dig into all of these.

But first, let's talk about the Stack and the Heap. Because if you do not understand these two, you will keep writing bugs without knowing why.

Stack vs Heap: Where Your Data Actually Lives

This is the concept that separates beginners from intermediate Java developers. I am going to break it down in the simplest way I can.

The Stack: Your Method's Personal Workspace

Every time you call a method, the JVM creates a new stack frame and pushes it onto the Stack. This frame holds:

Local variables (primitives like int, boolean, char)
References to objects (just the address, not the object itself!)
The return address (where to go back after the method finishes)

When the method finishes? The frame gets popped off. Gone. Memory freed instantly.

public class StackDemo {
    public static void main(String[] args) {
        int result = add(5, 3);  // main() frame is on the stack
        System.out.println(result);
    }

    static int add(int a, int b) {  // add() frame pushed on top
        int sum = a + b;  // sum lives in add()'s stack frame
        return sum;  // add() frame gets popped, sum disappears
    }
}

Here is what the Stack looks like during execution:

|                    |
|  add() frame       |  <-- top (current method)
|    a = 5           |
|    b = 3           |
|    sum = 8         |
|--------------------|
|  main() frame      |  <-- waiting for add() to finish
|    result = ?      |
|    args = ref      |
|--------------------|

When add() returns, its frame vanishes:

|                    |
|  main() frame      |  <-- now this is the top
|    result = 8      |
|    args = ref      |
|--------------------|

The Heap: Where Objects Actually Live

Every time you use the new keyword, the JVM creates an object on the Heap.

Student s = new Student("Tahosin", 22);

What happens here? Two things:

The Student object with name="Tahosin" and age=22 is created on the Heap
The variable s on the Stack stores the memory address (reference) of that object

The variable s does NOT contain the Student. It contains something like 0x7f3a2b which is the address where the Student object lives in the Heap.

public class HeapDemo {
    public static void main(String[] args) {
        Student s1 = new Student("Alice");
        Student s2 = new Student("Bob");
        Student s3 = s1;  // s3 points to the SAME object as s1

        System.out.println(s1 == s3);  // true  (same reference)
        System.out.println(s1 == s2);  // false (different objects)
    }
}

Quick Decision Table

What you created	Where it lives	When it dies
`int x = 10;`	Stack	When the method returns
`new Student()`	Heap	When Garbage Collector cleans it
`String name = "hi";`	Heap (String Pool)	When no references remain
Method parameters	Stack	When the method returns
Instance variables	Heap (inside the object)	When the object is garbage collected

The StackOverflowError You Keep Getting

Now you know why this happens:

public static void infinite() {
    infinite();  // Each call adds a new frame to the stack
}
// Eventually the stack runs out of space = StackOverflowError!

Every recursive call pushes a new frame. The Stack has a fixed size. Call too many methods without returning, and BOOM. Now you actually understand the error instead of just googling it.

How Java Cleans Up After You: Garbage Collection

In C or C++, you have to manually free memory when you are done with it. Forget to do it? Memory leak. Do it wrong? Segfault. Your program crashes, your weekend is ruined.

Java says "nah, I got this" and handles it automatically through Garbage Collection (GC).

How Does the GC Know What to Clean?

Simple rule: if an object on the Heap has no references pointing to it from the Stack (or from other reachable objects), it is garbage. The GC will eventually destroy it and free the memory.

public void createGarbage() {
    Student s = new Student("Alice");  // Object created on heap
    s = null;  // Reference removed. The Student object is now garbage!
    // GC will clean it up at some point
}

The Generational Approach

The JVM does not just have one big heap. It splits the heap into generations based on a simple observation: most objects die young.

Think about it. A temporary String you create inside a loop? Dead within milliseconds. A database connection pool? That lives for hours. Treating them the same would be wasteful.

So the Heap is divided into:

Young Generation (for short-lived objects):

Eden Space: Brand new objects are born here
Survivor Space S0 and S1: Objects that survive one GC cycle get moved here

Old Generation (for long-lived objects):

Objects that survive many GC cycles get "promoted" here

Here is the flow:

New object created
       |
       v
   Eden Space (Young Gen)
       |
       | Minor GC runs
       v
   Survived? ----No----> DELETED
       |
      Yes
       |
       v
   Survivor Space (S0/S1)
       |
       | Survived many cycles?
       v
      Yes -----> Old Generation
                       |
                       | Major GC runs (less frequent, more expensive)
                       v
                  Still alive? --No--> DELETED

Minor GC vs Major GC

Type	Where	How often	Speed
Minor GC	Young Generation	Very frequent	Fast (milliseconds)
Major GC	Old Generation	Rare	Slow (can pause your app!)

This is why you see performance tips like "avoid creating unnecessary objects in loops." Every object you create ends up in Eden, triggers more Minor GCs, and slows things down.

// BAD: Creates 10,000 String objects in the loop
for (int i = 0; i < 10000; i++) {
    String s = "Item " + i;  // Each + creates a new String
    process(s);
}

// BETTER: Reuse a StringBuilder
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) {
    sb.setLength(0);  // Reset without creating new object
    sb.append("Item ").append(i);
    process(sb.toString());
}

The JIT Compiler: Java's Secret Speed Weapon

Here is something that blows people's minds. Java can actually run faster than C in certain situations. How? Because of the JIT (Just-In-Time) Compiler.

The Problem with Pure Interpretation

When the JVM first starts running your bytecode, it uses an Interpreter. The interpreter reads each bytecode instruction one by one and executes it. This works, but it is slow. Way slower than running native machine code directly.

The JIT Solution

The JVM watches your code while it runs. It counts how many times each method gets called. When a method crosses a certain threshold (around 10,000 calls by default), the JVM says "hey, this method is HOT. It gets called all the time. Let me compile it to native machine code so it runs directly on the CPU."

This compiled native code gets cached. Next time that method is called, the JVM skips the interpreter entirely and runs the native code at full CPU speed.

// This method gets called 1 million times in a loop
public static int fibonacci(int n) {
    if (n <= 1) return n;
    return fibonacci(n - 1) + fibonacci(n - 2);
}

// First few thousand calls: interpreted (slow)
// After ~10,000 calls: JIT-compiled to native code (FAST)
// The JIT even optimizes things like inlining the recursive calls!

What Makes JIT Special

The JIT compiler has an advantage that ahead-of-time compilers like C's gcc do not have. The JIT can see runtime behavior.

Which branch of an if statement is taken 99% of the time? Optimize for that.
Is this method always called with the same argument? Specialize for it.
Is this virtual method always resolving to the same implementation? Inline it.

These are called speculative optimizations. The JIT makes bets based on what it observes at runtime, and those bets usually pay off big time.

// The JIT sees that 'animal' is always a Dog in practice
Animal animal = getAnimal();
animal.makeSound();

// So it optimizes this to directly call Dog.makeSound()
// without going through the virtual method dispatch table
// That is called "devirtualization" and it is insanely fast

Java is ALWAYS Pass-by-Value (Yes, Always)

This is the most confusing topic in Java for beginners, and I see wrong explanations everywhere. Let me set the record straight.

Java is always pass-by-value. There is no pass-by-reference in Java. Period. But what gets passed by value changes depending on what you are working with.

With Primitives: The Value Gets Copied

public static void main(String[] args) {
    int x = 10;
    changeValue(x);
    System.out.println(x);  // Still 10!
}

static void changeValue(int num) {
    num = 99;  // This changes the LOCAL copy, not the original
}

When you pass x to changeValue(), Java copies the value 10 into the parameter num. They are completely separate. Changing num does nothing to x.

With Objects: The Reference Value Gets Copied

public static void main(String[] args) {
    Dog myDog = new Dog("Buddy");
    changeName(myDog);
    System.out.println(myDog.getName());  // "Fido" -- Changed!
}

static void changeName(Dog d) {
    d.setName("Fido");  // Modifying the SAME object both references point to
}

Wait, if Java is pass-by-value, why did the name change?

Because Java copied the reference value (the memory address, like 0x1234) into the parameter d. Now both myDog and d hold the same address. They both point to the same Dog object on the heap. So when you call d.setName("Fido"), you are reaching through the copied address to modify the actual object.

The Proof: Reassignment Does Not Work

public static void main(String[] args) {
    Dog myDog = new Dog("Buddy");
    replaceDog(myDog);
    System.out.println(myDog.getName());  // Still "Buddy"!
}

static void replaceDog(Dog d) {
    d = new Dog("Max");  // This reassigns the LOCAL reference only
    // myDog in main() still points to the original Dog
}

If Java was pass-by-reference, myDog would now be "Max." But it is not. The parameter d was just a copy of the reference. Reassigning d to a new Dog only changes where the local copy points. The original myDog reference is untouched.

Here is the mental model:

Before replaceDog():
  myDog -----> [Dog: "Buddy"]  (address: 0x1234)

Inside replaceDog():
  d (copy) --> [Dog: "Buddy"]  (address: 0x1234)  // same object

After d = new Dog("Max"):
  myDog -----> [Dog: "Buddy"]  (address: 0x1234)  // unchanged
  d ---------> [Dog: "Max"]    (address: 0x5678)  // new object, local only

The String Pool: A Memory Hack You Should Know About

Strings are the most used objects in Java. Creating a new String object for every "hello" in your program would be a massive waste of memory.

So Java maintains a special area in the Heap called the String Pool (also called the String Intern Pool).

String a = "hello";
String b = "hello";
String c = new String("hello");

System.out.println(a == b);   // true  -- same object in String Pool
System.out.println(a == c);   // false -- c is a separate object on heap
System.out.println(a.equals(c));  // true -- same VALUE

// You can force a String into the pool
String d = c.intern();
System.out.println(a == d);   // true -- now d points to the pooled "hello"

Here is what this looks like in memory:

HEAP:
  String Pool:
    +-------------------+
    |   "hello"  (0x100)|  <-- a and b point here
    +-------------------+
    |   "world"  (0x200)|
    +-------------------+

  Regular Heap:
    +-------------------+
    |   "hello"  (0x300)|  <-- c points here (separate object!)
    +-------------------+

STACK:
  a = 0x100  (String Pool)
  b = 0x100  (String Pool)
  c = 0x300  (Regular Heap)
  d = 0x100  (String Pool, after intern())

Why This Matters

This is why every Java tutorial tells you to compare Strings with .equals() instead of ==.

== compares references (are they the same object in memory?)
.equals() compares values (do they contain the same characters?)

// This works by accident (both from String Pool)
String x = "hello";
String y = "hello";
System.out.println(x == y);  // true, but this is FRAGILE

// This breaks (new creates a separate object)
String z = new String("hello");
System.out.println(x == z);  // false!

// ALWAYS use .equals() for String comparison
System.out.println(x.equals(z));  // true, RELIABLE

Bonus: Prove It All Yourself

Here is a complete program you can run on your machine to see all of this in action:

public class JVMExplorer {
    public static void main(String[] args) {
        System.out.println("========================================");
        System.out.println("  EXPERIMENT 1: Stack vs Heap");
        System.out.println("========================================");

        int primitive = 42;  // Lives on the Stack
        String obj = new String("Hello JVM!");  // Object on Heap, reference on Stack

        System.out.println("Primitive value: " + primitive);
        System.out.println("Object value: " + obj);
        System.out.println("Object hashCode: " + System.identityHashCode(obj));
        System.out.println();

        System.out.println("========================================");
        System.out.println("  EXPERIMENT 2: String Pool");
        System.out.println("========================================");

        String s1 = "Java";
        String s2 = "Java";
        String s3 = new String("Java");

        System.out.println("s1 == s2 (both from pool): " + (s1 == s2));
        System.out.println("s1 == s3 (pool vs new):    " + (s1 == s3));
        System.out.println("s1.equals(s3):             " + s1.equals(s3));
        System.out.println("s1 == s3.intern():         " + (s1 == s3.intern()));
        System.out.println();

        System.out.println("========================================");
        System.out.println("  EXPERIMENT 3: Pass-by-Value Proof");
        System.out.println("========================================");

        int num = 100;
        modifyPrimitive(num);
        System.out.println("After modifyPrimitive: num = " + num);

        int[] arr = {1, 2, 3};
        modifyArray(arr);
        System.out.println("After modifyArray: arr[0] = " + arr[0]);

        int[] arr2 = {10, 20, 30};
        reassignArray(arr2);
        System.out.println("After reassignArray: arr2[0] = " + arr2[0]);
        System.out.println();

        System.out.println("========================================");
        System.out.println("  EXPERIMENT 4: Garbage Collection");
        System.out.println("========================================");

        Runtime runtime = Runtime.getRuntime();
        long beforeMem = runtime.totalMemory() - runtime.freeMemory();

        // Create a bunch of objects
        for (int i = 0; i < 100000; i++) {
            String garbage = new String("Temporary object #" + i);
        }

        long afterMem = runtime.totalMemory() - runtime.freeMemory();
        System.out.println("Memory before: " + beforeMem / 1024 + " KB");
        System.out.println("Memory after creating 100k objects: " + afterMem / 1024 + " KB");

        System.gc();  // Suggest GC to run (no guarantee!)
        long afterGC = runtime.totalMemory() - runtime.freeMemory();
        System.out.println("Memory after GC: " + afterGC / 1024 + " KB");
        System.out.println("GC freed roughly: " + (afterMem - afterGC) / 1024 + " KB");
        System.out.println();

        System.out.println("========================================");
        System.out.println("  EXPERIMENT 5: JVM Runtime Info");
        System.out.println("========================================");

        System.out.println("Available processors: " + runtime.availableProcessors());
        System.out.println("Max memory: " + runtime.maxMemory() / (1024 * 1024) + " MB");
        System.out.println("Total memory: " + runtime.totalMemory() / (1024 * 1024) + " MB");
        System.out.println("Free memory: " + runtime.freeMemory() / (1024 * 1024) + " MB");
        System.out.println("Java version: " + System.getProperty("java.version"));
        System.out.println("JVM name: " + System.getProperty("java.vm.name"));
    }

    static void modifyPrimitive(int x) {
        x = 999;  // Only modifies local copy
    }

    static void modifyArray(int[] a) {
        a[0] = 999;  // Modifies the actual array (same reference)
    }

    static void reassignArray(int[] a) {
        a = new int[]{999, 888, 777};  // Reassigns local reference only
    }
}

Run this. Read the output. Change things. Break things. That is how you actually learn the JVM.

The Complete Cheat Sheet

Concept	What Actually Happens
`javac MyApp.java`	Compiles to bytecode (.class), NOT machine code
`java MyApp`	JVM loads bytecode, interprets it, JIT compiles hot methods
`int x = 10;`	Value 10 stored directly on the Stack
`new Student()`	Object created on the Heap, reference stored on Stack
Method call	New stack frame pushed
Method return	Stack frame popped, local vars gone
`String s = "hi"`	Checks String Pool first, reuses if found
`new String("hi")`	Always creates new object on Heap (bypasses pool)
Pass primitive to method	Value is COPIED
Pass object to method	Reference is COPIED (same object, new pointer)
No more references to object	GC eventually frees the memory
Hot method (10,000+ calls)	JIT compiles to native machine code
`StackOverflowError`	Too many method calls, stack ran out of space
`OutOfMemoryError`	Heap is full, GC cannot free enough space

Wrapping Up

Java is not just a language. It is an entire platform with a virtual machine that does an incredible amount of work to make your code run fast, safe, and portable. Most developers use Java for years without understanding any of this, and that is fine for writing basic code. But the moment you hit a weird bug, a performance issue, or a tricky interview question, this knowledge becomes your superpower.

Here is what you should take away from this:

Your code does not run directly on the CPU. The JVM is the middleman.
Stack is for method execution and local primitives. Heap is for objects.
The Garbage Collector handles memory management, but creating fewer short-lived objects helps performance.
The JIT Compiler makes Java fast by converting hot methods to native code at runtime.
Java is always pass-by-value. Always. For objects, it copies the reference, not the object.
Use .equals() for String comparison, not ==.

Now go experiment. Run that JVMExplorer class. Add your own tests. See what happens when you create circular references. See what happens when you exhaust the stack. The best way to understand the JVM is to push it to its limits and watch how it responds.

What part of this surprised you the most? Did you already know about the JIT Compiler, or was that new? I would love to hear your thoughts and questions in the comments. And if you have a tricky JVM behavior you have encountered, share it below. Let's learn from each other.

Pointers Aren't Arrows. How C and C++ Actually Talk to Hardware.

S M Tahosin — Fri, 25 Sep 2026 12:12:28 +0000

Ask any software engineer to draw a pointer on a whiteboard.

Within three seconds, they will sketch two boxes and a little curved arrow pointing between them.

It looks neat. It feels intuitive. Computer science lectures have used that exact drawing for four decades.

And yet, that single diagram is why so many developers hit a psychological brick wall when learning C or C++.

Arrows don't exist inside your computer.

There is no wire inside your CPU labeled "arrow." There is no register that stores "direction." When you draw an arrow, you hide the one fundamental truth that makes low-level programming click:

A pointer is just an ordinary integer holding a street address.

The moment you discard the arrow and look at your computer through the eyes of the silicon, everything that felt terrifying about C and C++ suddenly turns simple. Pointer arithmetic stops looking like dark magic. Array decay makes total sense. And even the dreaded Segmentation Fault transforms from a random nightmare into a protective feature of your operating system.

Let us open the machine and see how C and C++ actually touch hardware.

The Memory Street: What RAM Actually Looks Like

Forget about files, variables, and objects for a moment.

To your CPU, system memory (RAM) is nothing more than one gigantic, continuous street of numbered byte lockers.

Every locker holds exactly one byte (8 bits).

And every single locker has a sequential house number. That house number is what we call an address.

Locker Address:  0x1000   0x1001   0x1002   0x1003   0x1004   0x1005
Stored Value:   [ 0x2A ] [ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x48 ] [ 0x69 ]

When you write a normal variable in C:

int score = 42;

The compiler does not build a box labeled "score."

Instead, it reserves 4 consecutive byte lockers (because a 32-bit int needs 4 bytes), writes 42 in binary into those lockers, and records in its internal symbol table:

Whenever this programmer writes score, look up locker number 0x1000.

The name score exists only for human readability. Once your code compiles into machine instructions, the name disappears forever. The CPU only ever sees numeric addresses.

Shattering the Arrow Lie

Now introduce a pointer:

int score = 42;
int* ptr = &score;

The ampersand & is the address-of operator. It simply asks: "What is the house number where score lives?"

If score lives at address 0x1000, then &score evaluates to the number 0x1000.

ptr is a variable just like any other. It needs space to live. The compiler reserves lockers for it at address 0x2000.

What value does the compiler store inside ptr?

It stores the number 0x1000. That is all. Nothing more, nothing less.

On a modern 64-bit operating system, every address is 64 bits wide (8 bytes). That means every pointer variable occupies exactly 8 bytes of memory, regardless of what type it points to.

You can verify this in your terminal:

#include <stdio.h>

struct HugePayload {
    char data[10000];
};

int main(void) {
    char* c_ptr;
    int* i_ptr;
    struct HugePayload* struct_ptr;

    printf("char* size:   %zu bytes\n", sizeof(c_ptr));
    printf("int* size:    %zu bytes\n", sizeof(i_ptr));
    printf("struct* size: %zu bytes\n", sizeof(struct_ptr));

    return 0;
}

Output:

char* size:   8 bytes
int* size:    8 bytes
struct* size: 8 bytes

If a pointer was an arrow, pointing to a 10,000-byte struct might require a bigger arrow than pointing to a 1-byte char.

In reality, a house number is always the same length, whether the house is a tiny studio apartment or a sprawling warehouse. It is just an address.

Dereferencing (*ptr) simply tells the CPU:

Read the house number stored inside ptr (0x1000). Go to locker 0x1000. Read or write the bytes living there.

Why `ptr + 1` Doesn't Add One (Pointer Arithmetic)

Look at this common beginner surprise:

int numbers[3] = {10, 20, 30};
int* p = &numbers[0];

printf("Before: %p\n", (void*)p);
p = p + 1;
printf("After:  %p\n", (void*)p);

You might expect adding 1 to increment the address by 1. But run it:

Before: 0x1000
After:  0x1004

It skipped 4 bytes.

Why? Because the compiler knows p is an int*. An int occupies 4 bytes.

If p + 1 moved forward by only 1 byte, p would point into the middle of the integer's binary representation, reading corrupted data.

During pointer arithmetic, the compiler scales every step by the size of the underlying type:

Destination Address = Current Address + (Step * sizeof(*p))

For char* (1 byte), p + 1 moves forward by 1 byte.
For int* (4 bytes), p + 1 moves forward by 4 bytes.
For double* (8 bytes), p + 1 moves forward by 8 bytes.

This explains why arithmetic on a void* is disallowed in standard ISO C. Because void has no defined size, the compiler cannot calculate how many bytes to step forward down the street.

The Array Decay Shock: Why `arr[i]` Equals `i[arr]`

In languages like JavaScript or Java, an array is an object with methods and length properties.

In C and C++, an array has zero runtime metadata.

An array is simply a contiguous strip of byte lockers sitting side by side.

When you declare:

int arr[4] = {10, 20, 30, 40};

The compiler places four 4-byte integers consecutively: 0x1000, 0x1004, 0x1008, and 0x100C.

In the C specification, the bracket syntax arr[i] is defined as:

arr[i] is identical to: *(arr + i)

The brackets are just syntactic sugar for pointer arithmetic and dereferencing.

Because addition is commutative (a + b == b + a), *(arr + 2) is identical to *(2 + arr).

And since *(arr + 2) is written as arr[2], then *(2 + arr) can be written as 2[arr].

#include <stdio.h>

int main(void) {
    int arr[4] = {10, 20, 30, 40};

    printf("arr[2]   = %d\n", arr[2]);
    printf("*(arr+2) = %d\n", *(arr + 2));
    printf("2[arr]   = %d\n", 2[arr]);

    return 0;
}

Output:

arr[2]   = 30
*(arr+2) = 30
2[arr]   = 30

Do not write 2[arr] in production code, but understanding why it works clarifies the architecture: in C, arrays don't have magical lookup engines. There are only base addresses, offsets, and byte fetches.

Stack vs. Heap: Physical Reality Inside Your RAM

Where do these street addresses come from?

When your program launches, the operating system assigns it a virtual memory territory divided into two primary working zones: The Stack and The Heap.

The Stack: A Single CPU Register

The stack is fast because it requires almost no bookkeeping.

Your CPU has a dedicated hardware register called RSP (Stack Pointer on x86_64).

When you call a function with local variables:

void calculate(void) {
    int a = 10;
    int b = 20;
}

The CPU executes a single assembly instruction:

sub rsp, 16

In less than a nanosecond, the stack pointer moves down by 16 bytes. That newly opened space belongs to a and b.

When the function exits:

add rsp, 16
ret

The stack pointer slides back up. Deallocation is instant.

Notice: the CPU never cleared those memory bytes. They still sit in the lockers. The stack pointer simply moved past them. The next function called will overwrite them. This is why uninitialized local variables in C hold random garbage data.

The Heap: The Dynamic Warehouse

When data must outlive the function that created it, or when its size is only known at runtime, you allocate from the Heap:

int* buffer = (int*)malloc(1024 * sizeof(int));

malloc cannot just subtract a register. The heap allocator (like glibc's ptmalloc) searches linked lists of free memory bins for a suitable block. If it runs out of pre-allocated space, it issues a kernel system call (brk or mmap) to expand its boundary.

When finished, you release the block:

free(buffer);

The Dangling Pointer Trap

What happens when you call free(buffer)?

The allocator marks that memory block as available for future allocations.
It does NOT touch the buffer variable.
It does NOT erase the bytes in memory.

buffer still holds the old address. If you access *buffer later, you trigger a Use-After-Free bug. Another thread or function may have received that address, meaning you will read or overwrite someone else's live data.

The fix is immediate:

free(buffer);
buffer = NULL;

What Actually Happens During a Segmentation Fault?

Consider the classic crash:

int* ptr = NULL;
*ptr = 100;

Your program immediately halts with:

Segmentation fault (core dumped)

What actually happened in the machine during that millisecond?

Your code did not break physical RAM. Your pointer never touched physical RAM in the first place.

The Hardware Guardian: The MMU

Modern operating systems never expose raw physical memory directly to applications. Instead, they use Virtual Memory.

Between your CPU core and physical memory sits the MMU (Memory Management Unit).

Memory is organized into 4KB pages. The operating system maintains a Page Table that maps virtual pages to physical RAM frames:

Virtual page 0x1000 maps to Physical RAM 0x8A40 (Read/Write).
Virtual page 0x0000 (NULL) is Unmapped (No access allowed).

When you execute *ptr = 100 with ptr = NULL:

The CPU sends address 0x0 to the MMU.
The MMU looks up 0x0 in the Page Table and finds no valid mapping.
The MMU blocks the write and triggers a Hardware Page Fault Exception (CPU Interrupt 14).
The CPU pauses your program and transfers control to the OS kernel.
The kernel identifies the violation and sends signal 11 (SIGSEGV) to your process.
With no custom signal handler registered, the OS terminates the process to protect system stability.

A Segmentation Fault is not a computer malfunction. It is your operating system's security barrier actively preventing illegal memory corruption.

Double Pointers: Demystifying `**ptr`

Double pointers (char**, int**) often confuse learners because people try to visualize stacked arrows.

Use the street address model instead:

A regular variable holds data (val = 42).
A single pointer (ptr) holds the house number of data (0x1000).
A double pointer (pptr) holds the house number of another pointer variable (0x2000).

int val = 99;       // Address 0x1000: holds 99
int* ptr = &val;    // Address 0x2000: holds 0x1000
int** pptr = &ptr;  // Address 0x3000: holds 0x2000

Why do we need this?

Because C passes all arguments by value (copying them).

If you want a function to modify an integer in the caller, you pass its address (int*).

Similarly, if you want a function to allocate memory and modify a pointer in the caller, you must pass the pointer's address (int**):

void allocate_memory(int** p) {
    *p = (int*)malloc(sizeof(int)); // Modifies the caller's pointer variable
}

int main(void) {
    int* data = NULL;
    allocate_memory(&data); // Pass address of data
    *data = 42;
    free(data);
    return 0;
}

When you see **p, don't think about arrows. Think: "I am receiving the address of a pointer so I can rewrite where it points."

Practical Mental Model: The Survival Cheat Sheet

Syntax / Concept	The Arrow Lie	The Hardware Reality
`int* ptr`	A line pointing to an integer	An 8-byte variable storing a memory address
`&x`	Drawing an arrow	Extracting the numeric locker number of `x`
`*ptr`	Following the arrow	Telling the CPU to read or write bytes at that address
`ptr + 1`	Advancing one box	`address + (1 * sizeof(*ptr))` bytes forward in RAM
`arr[i]`	Array lookup	Shorthand for `*(arr + i)`. Direct address offset.
`free(ptr)`	Wiping data	Returning the address reservation to the heap manager
`NULL` (`nullptr`)	Empty space	Address `0x0`. Guaranteed unmapped to trigger an MMU trap
Segfault	Program glitch	Hardware MMU exception caught by the OS for illegal access

The Shift That Makes Everything Click

High-level languages like Python and JavaScript provide garbage collection and abstraction to protect developers from raw memory. That convenience is valuable, but it obscures how computers work at the silicon level.

C and C++ strip away that insulation and hand you direct control of the memory bus.

Pointers are not mysterious entities or floating arrows. They are simply the numeric coordinates your computer uses every microsecond to execute software.

Once you picture memory as a numbered street of byte lockers, pointer arithmetic, array decay, and memory allocation all fall into place. You write cleaner code, avoid subtle memory corruption bugs, and truly understand the hardware beneath your programs.

If you have ever wrestled with a baffling segfault or a pointer bug in C or C++, what was the bug, and what was the moment that finally made pointers click for you?

Python Thinks Different: What Actually Happens Inside Your Code (Visual Guide)

S M Tahosin — Thu, 24 Sep 2026 04:02:22 +0000

Stop. Before you scroll past this, let me ask you something.

When you write x = 10 in Python, what do you think happens?

If your answer is "Python puts the number 10 inside a box called x," you are wrong. And honestly? That wrong mental model is the reason behind 90% of the confusing bugs beginners run into.

I spent a full week going down the rabbit hole of CPython source code, reading PEPs, and running weird experiments in my terminal. What I found completely changed how I write Python. And today, I want to share all of it with you.

Let's pull back the curtain on what Python is actually doing with your code.

The Biggest Lie You Were Told About Variables

Every beginner tutorial starts the same way. "Variables are like boxes. You put values in them."

Sounds logical. Feels right. But it is dead wrong in Python.

In Python, variables are name tags, not boxes. When you write x = 10, Python does not stuff the number 10 into some container called x. Instead, Python creates an object (the integer 10) somewhere in memory, and then sticks a label called x on it.

Think about it like luggage tags at an airport. The tag does not hold your suitcase. It just tells you which suitcase to grab.

Let's prove it with actual code

x = 10
y = x

print(id(x))  # 140712834816848
print(id(y))  # 140712834816848  <- SAME address!

print(x is y)  # True

Wait, x and y have the same memory address? Yes. Because y = x does not copy the value. It sticks another label on the same object.

This is the foundation of everything in Python. Get this right, and the rest falls into place.

Everything in Python is an Object. Seriously, Everything.

I know you have heard this before. But do you actually understand what it means?

In Python, the number 42 is not just a raw value floating around in memory. It is a full-blown object with:

A type (int)
A value (42)
A reference count (how many names point to it)
An id (its address in memory)

Check this out:

x = 42

print(type(x))           # <class 'int'>
print(x.__class__)       # <class 'int'>
print(isinstance(x, object))  # True

# Even functions are objects!
def greet():
    return "Hello"

print(type(greet))        # <class 'function'>
print(greet.__class__)    # <class 'function'>
print(isinstance(greet, object))  # True

Functions, classes, modules, even None itself. All objects. Every single thing in Python lives as an object on the heap.

Quick quiz for you

What does this print?

print(type(type))

Answer: <class 'type'>. The type of type is type itself. Mind bending, right? This is how Python bootstraps its entire type system.

Mutable vs Immutable: The Bug Factory

Here is where beginners lose hours of their lives debugging.

Immutable objects (int, str, tuple, frozenset)

When you "change" an immutable object, Python does not modify the original. It creates a brand new object and re-points your variable to it.

x = 10
print(id(x))  # 140712834816848

x = x + 1
print(id(x))  # 140712834816880  <- DIFFERENT address!

See that? The id changed. Python made a completely new object (11) and moved the x label to point at it. The old object (10) is still out there, untouched.

Mutable objects (list, dict, set)

This is where things get spicy. Mutable objects can be changed in place.

a = [1, 2, 3]
b = a  # b is just another label on the SAME list

b.append(4)

print(a)  # [1, 2, 3, 4]  <- Wait, I only changed b!
print(b)  # [1, 2, 3, 4]

print(a is b)  # True  <- They are literally the same object

This is not a bug. This is by design. Both a and b are labels on the same list object. When you modify the list through b, you are modifying the same list that a is looking at.

The "default argument" trap

This one has bitten every Python developer at least once:

def add_item(item, items=[]):
    items.append(item)
    return items

print(add_item("apple"))   # ['apple']
print(add_item("banana"))  # ['apple', 'banana']  <- Huh?!

The default list [] is created ONCE when the function is defined, not every time the function is called. Every call shares the same list object.

The fix:

def add_item(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

print(add_item("apple"))   # ['apple']
print(add_item("banana"))  # ['banana']  <- Fixed!

How Python Cleans Up After You: Garbage Collection

You never call free() or delete in Python. So who is cleaning up all those objects you stopped using?

Python uses two strategies working together:

Strategy 1: Reference Counting

Every object has a counter tracking how many names point to it. When that counter hits zero, the object gets deleted immediately.

import sys

a = "hello"
print(sys.getrefcount(a))  # 2 (one for 'a', one for the getrefcount argument)

b = a
print(sys.getrefcount(a))  # 3

del b
print(sys.getrefcount(a))  # 2

del a
# The "hello" object's refcount drops.
# If it hits 0, Python immediately frees the memory.

Strategy 2: Cycle Detection (for circular references)

Reference counting alone cannot handle this:

# A points to B, B points to A. Both have refcount > 0 forever!
a = []
b = []
a.append(b)
b.append(a)

del a
del b
# Both objects still reference each other.
# Refcount never hits 0, but nobody can access them!

This is where Python's generational garbage collector kicks in. It periodically scans for groups of objects that only reference each other with no outside connections, and cleans them up.

import gc

# You can see the garbage collector's thresholds
print(gc.get_threshold())  # (700, 10, 10)

# Generation 0: checked every 700 allocations
# Generation 1: checked every 10 Gen-0 collections
# Generation 2: checked every 10 Gen-1 collections

# Force a collection
collected = gc.collect()
print(f"Garbage collector freed {collected} objects")

Python's Secret Speed Hack: Integer Caching

Here is something that blows people's minds when they first discover it.

# Inside the cache range (-5 to 256)
a = 256
b = 256
print(a is b)  # True  <- Same object!

# Outside the cache range
a = 257
b = 257
print(a is b)  # False  <- Different objects!

# Negative numbers too
a = -5
b = -5
print(a is b)  # True

a = -6
b = -6
print(a is b)  # False

When Python starts up, it pre-creates objects for every integer from -5 to 256 and reuses them everywhere. Why? Because these numbers show up constantly in real code (loop counters, array indices, boolean operations), and creating a fresh object every time would be slow.

This is why you should never use is to compare values. Use == instead. The is operator checks if two variables point to the same object in memory. The == operator checks if two variables have the same value.

# Always use == for value comparison
a = 257
b = 257
print(a == b)  # True  <- Correct way to compare values
print(a is b)  # False <- This checks identity, not equality!

Python also caches strings (sometimes)

a = "hello"
b = "hello"
print(a is b)  # True  <- Python interned this string

a = "hello world!"
b = "hello world!"
print(a is b)  # False <- Strings with spaces/special chars? Not cached.

Short, identifier-like strings get "interned" (cached) automatically. This helps speed up dictionary lookups and attribute access.

Shallow Copy vs Deep Copy: Know the Difference

This is hands down one of the most confusing topics for beginners, and one of the most common sources of bugs in production code.

Assignment (no copy at all)

original = [[1, 2], [3, 4]]
alias = original  # Just another name. No copy.

alias[0][0] = 99
print(original)  # [[99, 2], [3, 4]]  <- Changed!

Shallow Copy

import copy

original = [[1, 2], [3, 4]]
shallow = copy.copy(original)

# The outer list is new
print(original is shallow)  # False

# But the inner lists are SHARED
print(original[0] is shallow[0])  # True

shallow[0][0] = 99
print(original)  # [[99, 2], [3, 4]]  <- Still linked!

Deep Copy

import copy

original = [[1, 2], [3, 4]]
deep = copy.deepcopy(original)

# Everything is new, at every level
print(original is deep)        # False
print(original[0] is deep[0])  # False

deep[0][0] = 99
print(original)  # [[1, 2], [3, 4]]  <- Safe!

Quick decision guide

Situation	What to use
I just need another name for the same data	`alias = original`
I need a new list, but inner data can be shared	`copy.copy()` or `list()` or `[:]`
I need a completely independent clone	`copy.deepcopy()`

The `slots` Trick: Saving Memory Like a Pro

By default, every Python object stores its attributes in a dictionary (__dict__). That dictionary takes up a lot of memory.

If you know exactly what attributes your class will have, you can use __slots__ to skip the dictionary entirely.

import sys

class PlayerWithDict:
    def __init__(self, name, score):
        self.name = name
        self.score = score

class PlayerWithSlots:
    __slots__ = ['name', 'score']

    def __init__(self, name, score):
        self.name = name
        self.score = score

# Let's compare memory usage
player_dict = PlayerWithDict("Tahosin", 100)
player_slots = PlayerWithSlots("Tahosin", 100)

print(sys.getsizeof(player_dict.__dict__))  # 296 bytes (the dict alone!)
print(sys.getsizeof(player_slots))           # 48 bytes (total!)

When you are creating millions of objects (game entities, data records, API responses), the difference adds up fast.

# Real-world impact: Creating 1 million player objects
import tracemalloc

tracemalloc.start()

# Without __slots__
players_dict = [PlayerWithDict(f"Player_{i}", i) for i in range(1_000_000)]
snapshot1 = tracemalloc.take_snapshot()

# Clear and restart
del players_dict
tracemalloc.stop()
tracemalloc.start()

# With __slots__
players_slots = [PlayerWithSlots(f"Player_{i}", i) for i in range(1_000_000)]
snapshot2 = tracemalloc.take_snapshot()

# The __slots__ version uses roughly 40-50% less memory!

Pass by What? Understanding Function Arguments

"Is Python pass by value or pass by reference?"

Neither. Python uses pass by object reference (sometimes called "pass by assignment").

When you pass an argument to a function, Python does not copy the value (pass by value) and does not give you a direct pointer to the variable (pass by reference). Instead, it creates a new local name that points to the same object.

def modify(data):
    # 'data' is a new name pointing to the SAME list
    data.append(4)  # Modifies the original object

numbers = [1, 2, 3]
modify(numbers)
print(numbers)  # [1, 2, 3, 4]  <- Changed!

def reassign(data):
    # This creates a BRAND NEW list and points 'data' to it
    data = [10, 20, 30]  # Only rebinds the local name
    print(f"Inside function: {data}")

numbers = [1, 2, 3]
reassign(numbers)
print(f"Outside function: {numbers}")  # [1, 2, 3]  <- Unchanged!

Here is the mental model:

Before function call:
  numbers -----> [1, 2, 3]

Inside modify():
  numbers -----> [1, 2, 3]    <- Both point to same list
  data    -----/

Inside reassign():
  numbers -----> [1, 2, 3]    <- numbers still points here
  data    -----> [10, 20, 30] <- data now points to a NEW list

The rule is simple: modifying the object through the new name affects the original. Rebinding the new name to a different object does not.

Bonus: Prove It All With `id()` and `sys.getrefcount()`

Here is a complete experiment you can run yourself to see all of this in action:

import sys

print("=" * 50)
print("EXPERIMENT 1: Variables are labels")
print("=" * 50)

x = [1, 2, 3]
y = x
print(f"id(x) = {id(x)}")
print(f"id(y) = {id(y)}")
print(f"Same object? {x is y}")
print(f"Ref count: {sys.getrefcount(x)}")
print()

print("=" * 50)
print("EXPERIMENT 2: Immutable rebinding")
print("=" * 50)

a = 42
print(f"Before: id(a) = {id(a)}")
a += 1
print(f"After a += 1: id(a) = {id(a)}")
print(f"Value of a: {a}")
print("The id changed because a new object was created!")
print()

print("=" * 50)
print("EXPERIMENT 3: Integer caching")
print("=" * 50)

for num in [0, 100, 256, 257, -5, -6]:
    a = num
    b = num
    print(f"  {num:>4}: a is b = {a is b}")
print()

print("=" * 50)
print("EXPERIMENT 4: String interning")
print("=" * 50)

s1 = "hello"
s2 = "hello"
s3 = "hello world"
s4 = "hello world"
print(f"  'hello': s1 is s2 = {s1 is s2}")
print(f"  'hello world': s3 is s4 = {s3 is s4}")

Run this on your own machine. Watch the outputs. Play with it. Change things. Break things. That is how you really learn this stuff.

Cheat Sheet: The Rules of Python's Object Model

Concept	What Python actually does
`x = 10`	Creates an int object (10), binds the name `x` to it
`y = x`	Binds the name `y` to the same object `x` points to
`x = x + 1`	Creates a NEW int object (11), rebinds `x` to it
`a.append(4)`	Modifies the list object in place, all names see the change
`del x`	Removes the name `x`, decrements refcount of its object
`x == y`	Compares values (use this!)
`x is y`	Compares identity / memory address (rarely use this)
`copy.copy()`	New outer container, shared inner objects
`copy.deepcopy()`	Completely independent clone at every level

Wrapping Up

Python looks simple on the surface. x = 10 feels like the most basic thing in the world. But underneath, there is a sophisticated system of objects, references, and memory management working together.

Understanding these internals does not make you a "theoretical" programmer. It makes you a better practical programmer because:

You will stop writing bugs caused by shared mutable objects
You will know when to copy data and when not to
You will write more memory-efficient code using __slots__
You will actually understand error messages about mutability
You will pass Python interviews with confidence

The next time someone says "variables are boxes," you will know better.

Now go run those experiments. Break something. That is how this stuff sticks.

What concept surprised you the most? Have you ever been bitten by the mutable default argument bug? I would love to hear your stories in the comments.

DEV Community: S M Tahosin

Your CPU Never Executes Java. The JVM Rewrites It at Runtime.

Wait, Java Does NOT Run Your Code Directly?

The Three Pillars Inside the JVM

1. The Class Loader

2. Runtime Data Areas (Stack and Heap)

3. The Execution Engine

Stack vs Heap: Where Your Data Actually Lives

The Stack: Your Method's Personal Workspace

The Heap: Where Objects Actually Live

Quick Decision Table

The StackOverflowError You Keep Getting

How Java Cleans Up After You: Garbage Collection

How Does the GC Know What to Clean?

The Generational Approach

Minor GC vs Major GC

The JIT Compiler: Java's Secret Speed Weapon

The Problem with Pure Interpretation

The JIT Solution

What Makes JIT Special

Java is ALWAYS Pass-by-Value (Yes, Always)

With Primitives: The Value Gets Copied

With Objects: The Reference Value Gets Copied

The Proof: Reassignment Does Not Work

The String Pool: A Memory Hack You Should Know About

Why This Matters

Bonus: Prove It All Yourself

The Complete Cheat Sheet

Wrapping Up

Pointers Aren't Arrows. How C and C++ Actually Talk to Hardware.

The Memory Street: What RAM Actually Looks Like

Shattering the Arrow Lie

Why ptr + 1 Doesn't Add One (Pointer Arithmetic)

The Array Decay Shock: Why arr[i] Equals i[arr]

Stack vs. Heap: Physical Reality Inside Your RAM

The Stack: A Single CPU Register

The Heap: The Dynamic Warehouse

The Dangling Pointer Trap

What Actually Happens During a Segmentation Fault?

The Hardware Guardian: The MMU

Double Pointers: Demystifying **ptr

Practical Mental Model: The Survival Cheat Sheet

The Shift That Makes Everything Click

Python Thinks Different: What Actually Happens Inside Your Code (Visual Guide)

The Biggest Lie You Were Told About Variables

Let's prove it with actual code

Everything in Python is an Object. Seriously, Everything.

Quick quiz for you

Mutable vs Immutable: The Bug Factory

Immutable objects (int, str, tuple, frozenset)

Mutable objects (list, dict, set)

The "default argument" trap

How Python Cleans Up After You: Garbage Collection

Strategy 1: Reference Counting

Strategy 2: Cycle Detection (for circular references)

Python's Secret Speed Hack: Integer Caching

Python also caches strings (sometimes)

Shallow Copy vs Deep Copy: Know the Difference

Assignment (no copy at all)

Shallow Copy

Deep Copy

Quick decision guide

The __slots__ Trick: Saving Memory Like a Pro

Pass by What? Understanding Function Arguments

Bonus: Prove It All With id() and sys.getrefcount()

Cheat Sheet: The Rules of Python's Object Model

Wrapping Up

Why `ptr + 1` Doesn't Add One (Pointer Arithmetic)

The Array Decay Shock: Why `arr[i]` Equals `i[arr]`

Double Pointers: Demystifying `**ptr`

The `slots` Trick: Saving Memory Like a Pro

Bonus: Prove It All With `id()` and `sys.getrefcount()`