Memory on Tachera W Sasi, Backend & Infra Engineer (Go, Self-Hosted, Observability)

What Building malloc Taught Me About Memory

Fri, 13 Mar 2026 00:00:00 +0000

—2" tags: [“clang”]

Modern developers rarely think about memory.

We call malloc, new, or let a garbage collector handle everything. Most of the time that’s perfectly fine. But recently I decided to dig deeper and implement a very small version of malloc myself.

Not to replace real allocators. Just to understand what actually happens under the hood.

The result was surprisingly simple and incredibly educational.

This post walks through the core ideas.

Why Understanding Memory Still Matters

Most software today runs on layers of abstraction.

Frameworks → languages → runtimes → operating systems.

That’s powerful, but it also means many developers never see the foundations those layers are built on.

Understanding memory allocation helps with:

• writing faster software
• debugging memory issues
• understanding how runtimes work
• building systems tools
• designing better APIs

Even if you work in higher level languages like Go , these concepts still power everything underneath.

Step 1: Where malloc Gets Memory

When a program runs, memory roughly looks like this:



Code
Globals
Heap ← grows upward
Stack ← grows downward

malloc allocates from the heap.

Under the hood, the allocator asks the OS for more heap space using a system call like sbrk().

Example:



void *ptr = sbrk(1024);

This moves the program break forward by 1024 bytes and returns a pointer to the new memory.

Think of it like extending the end of your program’s heap.

Step 2: The Naive Allocator

The simplest possible allocator would just call sbrk.



void *my_malloc(size_t size) {
 return sbrk(size);
}

But this immediately creates a problem.

If you later call free, the allocator has no idea :

• how big the allocation was
• where the next block starts
• whether a block can be reused

So real allocators store metadata.

Step 3: The Hidden Header Trick

Every allocation secretly stores a small header before the memory returned to the user.

Memory layout:



[ HEADER ][ USER MEMORY ]

The header might contain:



size
is_free
next_block

Example structure:



typedef struct block_header {
 size_t size;
 int is_free;
 struct block_header *next;
} block_header_t;

When the allocator returns memory, it actually returns a pointer after the header.



return (void *)(block + 1);

Which means the user sees:



ptr → usable memory

While the allocator still has its metadata.

Step 4: Tracking Allocations

Blocks are usually tracked using a linked list.



heap_start
 ↓
[block A] → [block B] → [block C]

When malloc runs:

search for a free block big enough
reuse it if possible
otherwise request more memory from the OS

This keeps allocations fast and avoids unnecessary system calls.

Step 5: What free Actually Does

One surprising thing: free usually does not return memory to the OS.

Instead it just marks the block as reusable.



[HEADER free=1][memory]

Future allocations can reuse that block instead of requesting more memory.

What Real Allocators Do Differently

Real allocators (like the ones used by glibc) add several optimizations:

Block splitting



Free block: 100 bytes
Need: 20

Split into:



20 used
80 still free

Block coalescing

Adjacent free blocks merge together to reduce fragmentation.

Large allocation handling

Large allocations often use mmap instead of the heap.

Thread safety

Modern allocators maintain thread local arenas for performance.

What I Learned From This

Building even a tiny allocator reinforced a few important lessons.

Abstractions hide complexity, but the fundamentals still matter

Languages like Go make memory management easier, but the underlying principles are still there.

Performance often comes from understanding the layers below you

Understanding memory layout and allocation patterns helps explain why some code performs better than others.

Systems knowledge compounds

Once you understand memory allocators, many other topics suddenly make more sense:

• garbage collectors
• runtime design
• kernel memory management
• high performance servers

Final Thoughts

You don’t need to write your own allocator for production software.

But building one, even a small version, forces you to think like the runtime.

And that perspective is valuable.

The more you understand the layers beneath your tools, the better engineer you become.

GITHUB => https://github.com/tacheraSasi/malloc.git

Originally published on Medium.

Escape Analysis in Go: Where Does Your Data Actually Live?

Fri, 20 Feb 2026 00:00:00 +0000

—2"

If you’ve been writing Go for a while, you’ve probably heard the terms stack and heap tossed around. But have you ever wondered how Go decides where to put your variables? That’s exactly what escape analysis is about and understanding it can help you write faster, more efficient Go code.

Stack vs Heap: A Quick Refresher

Think of memory in two buckets:

Stack Fast, automatically managed. When a function is called, variables are pushed onto the stack. When the function returns, they’re gone. No cleanup needed.
Heap Slower, but longer-lived. Variables here are managed by Go’s garbage collector (GC). They stick around as long as something is referencing them.

The stack is cheap. The heap costs more allocating on the heap puts pressure on the GC, which can slow your program down.

So What Is Escape Analysis?

Escape analysis is what the Go compiler does at compile time to figure out: “Does this variable need to live on the heap, or can it stay on the stack?”

If a variable is only used inside the function it was created in, it can safely live on the stack. But if a variable “escapes” meaning something outside the function needs to access it it has to be moved to the heap.

The compiler does this automatically. You don’t have to think about it most of the time. But understanding when things escape can help you avoid unnecessary heap allocations.

A Simple Example



func main() {
 x := 42
 fmt.Println(x)
}

Here, x is created and used inside main. It doesn’t escape anywhere. The compiler keeps it on the stack.

Now consider this:



func newNumber() *int {
 x := 42
 return &x // we're returning a pointer to x 
}

Here, we’re returning a pointer to x. That means after newNumber returns, something outside the function is still holding a reference to x. The stack for newNumber is gone at that point so Go moves x to the heap. It has escaped.

How to See What’s Escaping

Go gives you a handy compiler flag to inspect escape analysis decisions:

bash



go build -gcflags="-m" ./...

You’ll see output like:



./main.go:6:2: moved to heap: x
./main.go:10:13: ... argument does not escape

This tells you exactly which variables the compiler decided to allocate on the heap. It’s a great debugging tool when you’re trying to optimize performance.

Common Reasons a Variable Escapes

1. Returning a pointer to a local variable As shown above if you return &x, x has to live on the heap.

2. Storing a value in an interface



var i interface{} = 42

When you assign a concrete value to an interface, Go often needs to heap-allocate it because the interface value needs to carry around type information.

3. Sending to a channel or storing in a slice/map If the runtime can’t prove the value won’t outlive the current scope, it plays it safe and puts it on the heap.

4. Closures capturing variables



func makeCounter() func() int {
 count := 0
 return func() int {
 count++
 return count
 }
}

Here, count is captured by the closure returned from makeCounter. Since the closure can be called long after makeCounter returns, count escapes to the heap.

Does This Matter in Practice?

For most applications, not really Go’s garbage collector is fast and well-tuned. But in performance-sensitive code (think: game loops, high-frequency trading, large-scale data pipelines), reducing heap allocations can make a meaningful difference.

Here’s a rough guide:

Don’t return pointers to small, short-lived values if you don’t need to. Return by value instead.
Pre-allocate slices when you know the size upfront (make([]int, 0, 100)) to avoid repeated heap allocations.
Use**-gcflags= “-m” or benchmarks** to identify hot paths with lots of allocations before optimizing.

Key Takeaways

Go automatically decides whether variables live on the stack (fast, temporary) or the heap (slower, GC-managed).
This decision is made by the compiler using escape analysis.
A variable “escapes” to the heap when it needs to outlive the function it was created in.
You can inspect escape decisions with go build -gcflags="-m".
Understanding escape analysis helps you write more allocation-efficient Go code.

The beauty of Go is that you don’t have to think about this most of the time. But when performance matters, escape analysis is one of those things that separates good Go code from great Go code. Happy coding! 🚀

Originally published on Medium.