DEV Community: Rajat Negi

Building malloc from Scratch (Part 2): Bridging Linux, Windows, and Raw CPU Pages

Rajat Negi — Wed, 08 Jul 2026 19:38:43 +0000

Recapping Part 1

In Part 1, I focused on the design rather than the implementation. The allocator's scope, architecture, and core concepts were established before writing any code.

Scope

Cross-platform (Linux and Windows)
Page-backed
Explicit free-list
Written in C

Project Structure

memory-allocator/
├── include/
│   └── allocator.h
├── src/
│   ├── allocator.c
│   ├── block.c
│   ├── free_list.c
│   ├── utils.c
│   └── os/
│       ├── os.h
│       ├── linux.c
│       └── windows.c
└── tests/
    ├── Makefile
    └── test_os.c

Step 1: Defining the OS Interface
Step 2: Building the Platform Backends
- Linux Backend
- Windows Backend
Step 3: Utility Functions
Step 4: Testing the Platform Layer
What's Next

Step 1: Defining the OS Interface

The allocator itself should never know whether it is running on Linux or Windows.

Instead, it interacts with a very small platform abstraction layer. Every request for raw memory goes through this interface, allowing the rest of the allocator to remain completely platform-independent.

src/os/os.h

#ifndef OS_H
#define OS_H

#include <stddef.h>

/* Allocate memory directly from the operating system */
void *os_alloc(size_t size);

/* Release memory back to the operating system */
void os_free(void *ptr, size_t size);

/* Query the system page size */
size_t os_page_size(void);

#endif

These three functions form the boundary between the allocator and the operating system.

os_alloc() requests one or more pages.
os_free() releases previously allocated pages.
os_page_size() retrieves the system's page size so the allocator never relies on hardcoded values such as 4096.

Everything built later like block headers, free lists, splitting, coalescing, malloc(), calloc(), realloc(), and free() will depend on these functions rather than directly calling operating system APIs.

Step 2: Building the Platform Backends

The interface is identical across platforms.

Only the implementation changes.

On Linux, pages come from mmap(). On Windows, they come from VirtualAlloc().

Both implementations expose the same interface, allowing the allocator logic to remain unchanged regardless of the operating system.

Linux Backend

src/os/linux.c

#ifdef __linux__

#include "os.h"

#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>

void *os_alloc(size_t size) {
  void *ptr = mmap(
    NULL,
    size,
    PROT_READ | PROT_WRITE,
    MAP_PRIVATE | MAP_ANONYMOUS,
    -1,
    0
  );

  if (ptr == MAP_FAILED) {
    return NULL;
  }

  return ptr;
}

void os_free(void *ptr, size_t size) {
  if (ptr == NULL) {
    return;
  }

  if (munmap(ptr, size) == -1) {
    perror("munmap");
  }
}

size_t os_page_size(void) {
  long page_size = sysconf(_SC_PAGESIZE);

  if (page_size == -1) {
    return 4096;
  }

  return (size_t)page_size;
}

#endif

Rather than using the traditional process heap (sbrk()), this allocator requests independent virtual memory mappings using mmap().

The call is configured with four important arguments:

PROT_READ | PROT_WRITE gives the mapping read and write permissions.
MAP_PRIVATE ensures modifications remain private to the current process.
MAP_ANONYMOUS creates memory that is not backed by a file.
Passing NULL allows the kernel to choose an appropriate virtual address.

On success, mmap() returns a page-aligned, zero-initialized region of virtual memory.

If the mapping cannot be created, it returns MAP_FAILED. Rather than exposing Linux-specific error values to the allocator, the wrapper simply returns NULL, providing the same behavior expected from a typical allocation function.

Releasing memory is equally straightforward.

munmap() returns the mapped pages to the operating system. Unlike Windows, Linux requires the original allocation size when unmapping a region, which is why os_free() accepts both the pointer and the size.

Finally, os_page_size() queries the operating system using sysconf() instead of assuming a fixed page size. While 4096 bytes is common on modern desktop systems, other architectures may use different page sizes.

Windows Backend

src/os/windows.c

#ifdef _WIN32

#include "os.h"

#include <windows.h>

void *os_alloc(size_t size) {
  return VirtualAlloc(
    NULL,
    size,
    MEM_RESERVE | MEM_COMMIT,
    PAGE_READWRITE
  );
}

void os_free(void *ptr, size_t size) {
  (void)size;

  if (ptr == NULL) {
    return;
  }

  VirtualFree(ptr, 0, MEM_RELEASE);
}

size_t os_page_size(void) {
  SYSTEM_INFO info;
  GetSystemInfo(&info);

  return (size_t)info.dwPageSize;
}

#endif

Windows exposes virtual memory management through the VirtualAlloc() and VirtualFree() APIs.

Although the API differs from Linux, the overall idea is the same: request one or more pages directly from the operating system.

VirtualAlloc() combines two operations:

MEM_RESERVE reserves a range of virtual addresses.
MEM_COMMIT makes those pages immediately available for use.

Using both flags together gives the allocator writable, zero-initialized memory in a single call.

Unlike Linux, VirtualFree() does not require the allocation size when releasing memory. Windows keeps track of that information internally, so the wrapper simply ignores the unused size parameter while preserving the same cross-platform interface.

Retrieving the page size is handled through GetSystemInfo(), which fills a SYSTEM_INFO structure containing information about the running system, including the page size.

Although the Linux and Windows implementations use completely different operating system APIs, they expose the same three functions:

void *os_alloc(size_t size);
void os_free(void *ptr, size_t size);
size_t os_page_size(void);

From this point onward, the allocator no longer needs to care which operating system it is running on.

The platform-specific work ends here.

Everything that follows like block headers, free lists, splitting, coalescing, and the implementation of malloc() itself will be written entirely against this abstraction layer.

Step 3: Utility Functions

With the platform layer complete, the next step is building a few small helper functions that the allocator will rely on throughout the project.

These functions are not responsible for allocating memory. Instead, they provide common operations such as alignment, size comparisons, and block manipulation that will become useful once block headers and free lists are introduced.

src/utils.c

#include "allocator.h"

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

/* Alignment utilities */
size_t align_up(size_t value, size_t alignment) {
  return (value + alignment - 1) & ~(alignment - 1);
}

bool is_power_of_two(size_t value) {
  return (value != 0) && ((value & (value - 1)) == 0);
}

size_t max_size(size_t a, size_t b) {
  return (a > b) ? a : b;
}

/* Placeholder until BlockHeader exists */
bool blocks_are_adjacent(void *block1, void *block2) {
  (void)block1;
  (void)block2;
  return false;
}

Although this file is small, it introduces one of the most important ideas in allocator design: memory alignment.

Alignment

Modern processors expect many types of data to begin at addresses that are multiples of a specific value, typically 8 or 16 bytes on 64-bit systems.

Suppose a program requests:

malloc(3);

Returning exactly three bytes would leave the next allocation starting at an unaligned address.

Instead, allocators round allocations upward so every payload begins on the correct alignment boundary.

malloc(3)
      │
      ▼
Round up to 8 bytes
      │
      ▼
+--------+-----------+
| Header |  Payload  |
+--------+-----------+
      │
      ▼
Next allocation also begins on an aligned boundary

Proper alignment improves performance and is required by some processor architectures.

The helper responsible for this is align_up().

size_t align_up(size_t value, size_t alignment) {
  return (value + alignment - 1) & ~(alignment - 1);
}

Although the expression looks unusual, it performs two simple operations:

Add enough bytes to reach the next alignment boundary.
Clear the lower bits to round the value down to that boundary.

For example:

align_up(5, 8)  = 8
align_up(8, 8)  = 8
align_up(9, 8)  = 16

This works only when the alignment is a power of two.

To verify that assumption, the allocator includes another helper.

bool is_power_of_two(size_t value) {
  return (value != 0) && ((value & (value - 1)) == 0);
}

This relies on a common bit manipulation trick.

A power of two contains exactly one bit set.

If the result is zero, the value is a power of two.

The remaining helpers are much simpler.

max_size() returns the larger of two values and improves readability wherever block sizes need to be compared.

blocks_are_adjacent() is currently only a placeholder. Once block headers are introduced, it will determine whether two neighboring blocks can be merged during coalescing.

Step 4: Testing the Platform Layer

Before building the allocator itself, it is worth verifying that the platform abstraction layer behaves correctly.

At this stage, the goal is intentionally simple:

Query the system page size.
Request one page from the operating system.
Write data into that page.
Read it back.
Release the page.

If this works on both Linux and Windows, the allocator has a reliable foundation to build upon.

tests/test_os.c

#include <stdio.h>
#include <string.h>

#include "os/os.h"

int main(void) {
  printf("Testing OS abstraction layer...\n");

  size_t page_size = os_page_size();
  printf("Page size: %zu bytes\n", page_size);

  void *ptr = os_alloc(page_size);

  if (ptr == NULL) {
    fprintf(stderr, "Allocation failed!\n");
    return 1;
  }

  printf("Allocated %zu bytes at %p\n", page_size, ptr);

  const char *message = "Hello, Memory Allocator!";
  strcpy((char *)ptr, message);

  printf("Read back: \"%s\"\n", (char *)ptr);

  os_free(ptr, page_size);

  printf("Memory released successfully.\n");

  return 0;
}

The test is intentionally small.

No allocator has been implemented yet.

The only purpose is to verify that both platform backends expose identical behavior through the abstraction layer.

To simplify compilation, the project uses a small Makefile.

tests/Makefile

CC = gcc

CFLAGS = -Wall -Wextra -std=c11 -I../include -I../src

LDFLAGS =

UNAME_S := $(shell uname -s)

ifeq ($(UNAME_S),Linux)
  OS_BACKEND = ../src/os/linux.c
endif

ifeq ($(UNAME_S),Darwin)
  OS_BACKEND = ../src/os/linux.c
endif

ifeq ($(OS),Windows_NT)
  OS_BACKEND = ../src/os/windows.c
endif

all: test_os

test_os: test_os.c $(OS_BACKEND) ../src/utils.c
  $(CC) $(CFLAGS) -o $@ test_os.c $(OS_BACKEND) ../src/utils.c $(LDFLAGS)

clean:
  rm -f test_os

.PHONY: all clean

The Makefile selects the appropriate platform backend automatically.

Linux builds with linux.c.
Windows builds with windows.c.
macOS currently reuses the Linux backend because it also provides mmap().

Once built, run:

make
./test_os

A successful run should produce output similar to:

Testing OS abstraction layer...
Page size: 4096 bytes
Allocated 4096 bytes at 0x71002a37c000
Read back: "Hello, Memory Allocator!"
Memory released successfully.

At this point, the project can successfully communicate with the operating system, request pages, access them, and return them safely.

That is all the allocator needs before introducing its own memory management.

What's Next?

The platform abstraction layer is now complete.

The allocator can request pages from the operating system, determine the system page size, and release memory through a common interface that works on both Linux and Windows.

In the next part, those raw pages will become usable memory blocks.

We'll introduce block headers, define the allocator's internal metadata, and begin implementing the data structures that eventually power malloc(), calloc(), realloc(), and free().

Explore the project on GitHub

Building malloc from Scratch (Part 1): Architecture & Core Concepts

Rajat Negi — Wed, 08 Jul 2026 15:52:32 +0000

I wanted to understand how malloc actually works under the hood.

Most explanations I found online described what an allocator does, but completely skipped over the "why" behind its design decisions. Rather than stopping at theory, I decided to build a cross-platform allocator in C that implements malloc, calloc, realloc, and free from scratch.

This article documents the design of that allocator, the architectural tradeoffs I faced, and the core concepts I had to learn along the way.

Design Decisions
Architecture
Modern Allocator Strategies
Core Concepts
What's Next

Project Overview

A custom memory allocator does not create physical memory. Instead, it requests pages of raw virtual memory from the operating system and manages how that memory is partitioned, reused, resized, and released by the application.

The goal of this educational project is to implement C's core memory management API using a modular, cross-platform architecture inspired by design principles found in modern allocators, rather than relying on legacy, single-platform tricks.

Design Decisions

#1: Why I am Skipping `sbrk`

While many classic tutorials use sbrk for educational implementations, I deliberately chose a 100% mmap-based approach for two major reasons:

sbrk is a fragile global bottleneck. It works by moving a single pointer (the program break) up and down. This means the allocator assumes it owns a contiguous line of memory. If a third-party library or another thread in the program secretly calls sbrk behind the scenes, the allocator's memory layout can break instantly. mmap, by contrast, provides isolated, independent chunks of memory.
Cross-Platform Symmetry. Windows has absolutely no equivalent to sbrk, but it has a direct equivalent to mmap: VirtualAlloc. If we used sbrk, our architectural abstraction (os_alloc) would become awkward because Linux would deal with a moving pointer while Windows dealt with independent pages. Using mmap keeps the abstraction perfectly symmetrical: we ask for $N$ pages of memory, and the OS gives us a pointer.

#2: Scope

This project implements a cross-platform, page-backed explicit free-list memory allocator in C.

Cross-platform because the allocator separates platform-specific memory acquisition (mmap on Linux and VirtualAlloc on Windows) from the allocator logic.
Page-backed because it requests memory from the operating system in page-sized chunks instead of relying on the legacy sbrk interface.
Explicit free-list because free memory blocks are tracked using an explicit linked list, allowing blocks to be reused, split, and coalesced over time.
Modular because the allocator logic is isolated from platform-specific memory acquisition through a small OS abstraction layer.

This is not an arena allocator, a toy bump allocator, slab allocator, or production-grade allocator. The goal is to build a clean, modular allocator that demonstrates the fundamental algorithms and data structures behind dynamic memory management while remaining portable across Linux and Windows.

Architecture and Platform Abstraction

To keep the codebase clean, we decouple the high-level allocation logic (which is identical across platforms) from the low-level OS system calls. The only platform-specific layer is responsible for fetching and releasing large chunks of virtual memory.

Mental Model to Keep

Application
       │
[ malloc / calloc / realloc / free ]
       │
─────────────────────────────────
Allocator Logic
• free list
• splitting
• coalescing
• alignment
─────────────────────────────────
OS Abstraction
os_alloc()
os_free()
─────────────────────────────────
Linux             Windows
mmap()            VirtualAlloc()
munmap()          VirtualFree()

Project Directory Structure

memory-allocator/
├── include/
│   └── allocator.h
├── src/
│   ├── allocator.c       # Implementations of malloc, calloc, realloc, free
│   ├── block.c           # Block header manipulation (splitting, coalescing)
│   ├── free_list.c       # Free list management (allocation strategies)
│   ├── utils.c           # Alignment helpers and math utilities
│   └── os/               # OS abstraction layer
│       ├── os.h
│       ├── linux.c       # Linux mmap/munmap backend
│       └── windows.c     # Windows VirtualAlloc/VirtualFree backend
└── tests/
    ├── Makefile
    └── test_os.c

OS Abstraction Layer

The entire platform-specific interface is reduced to just two primary functions declared in os.h:

See the os.h header file

void *os_alloc(size_t size);
void  os_free(void *ptr, size_t size);

Linux Backend: Maps to mmap and munmap.
Windows Backend: Maps to VirtualAlloc and VirtualFree.

By abstracting these calls, core features like block headers, free-list management, memory splitting, coalescing, and data alignment remain completely platform-independent.

Modern Allocator Strategies

Historically, general-purpose allocators relied heavily on brk/sbrk for heap growth and used mmap primarily for larger allocations.

Modern production-grade allocators take a page-based or arena-based (extremely fast, used in games, compilers, parsers - where many objects have the same lifetime.) approach to minimize fragmentation and maximize multi-threaded performance:

Allocator	Strategy
`glibc malloc`	Dynamically mixes `brk` for small, short-lived objects and `mmap` for larger allocations.
`jemalloc`	Heavily relies on `mmap` to allocate large chunks ("extents"), optimizing for multi-threaded concurrency and core scaling.
`mimalloc`	Uses page mapping (`mmap`/`VirtualAlloc`) to slice memory into uniform-sized blocks, prioritizing predictability and free-list security.
`tcmalloc`	Thread-Caching allocator that utilizes a centralized page heap manager to distribute thread-local memory structures rapidly.

Core Concept

1. Virtual Memory

Before an allocator can manage memory, it's important to understand what kind of memory it is actually managing.

User programs do not manipulate physical RAM directly. Instead, every process is given its own virtual address space by the operating system. The kernel maps these virtual addresses onto physical memory as needed, providing isolation between processes and allowing techniques such as demand paging, memory mapping, and copy-on-write.

Region	Address Direction	Access Rights	Contents & Description
Protected Kernel Space	High to Low	Kernel Only (No User Access)	Operating system core, page tables, and drivers.
Stack	High to Low	r-w	Function arguments, local variables, and return addresses.
Mapped Memory	High to Low	r-w-x (Depends)	Memory-mapped files (`mmap`), shared libraries, and thread-local storage.
Heap	High to Low	r-w	Dynamically allocated memory (e.g., via `malloc` in C or `new` in C++).
Program Break (brk)	High to Low	r-w	The boundary/break marking the end of the data segment. It's not an actual region.
Text Segment	Low to High	r-x	The compiled machine code/instructions of the program.

2. Pages

Virtual memory is divided into fixed-size pages (typically 4 KiB on x86-64 Linux). The operating system maps and protects memory one page at a time rather than one byte at a time.

Consequently, functions like mmap() and VirtualAlloc() allocate memory in page-sized units. Our allocator will request pages from the operating system and then subdivide them into smaller blocks that satisfy individual malloc() requests.

OS Level:     [    4 KiB Page    ] -> [    4 KiB Page    ]
                     ↓                      ↓
Allocator:    [Block][Block][Block]   [Block][Block][Block]

This difference in granularity is the entire reason memory allocators exist. The OS manages the pages; our allocator manages the blocks within them.

3. Anonymous Mapping

This allocator requests anonymous memory mappings rather than mapping files. An anonymous mapping is simply a region of virtual memory backed by the OS rather than a file on disk. Anonymous pages are zero-filled when first mapped by the kernel.

Our OS abstraction layer will utilize this specific wrapper signature:

mmap(
    NULL,
    size,
    PROT_READ | PROT_WRITE,
    MAP_PRIVATE | MAP_ANONYMOUS,
    -1,
    0
);

I originally thought mmap() was only for mapping files. In reality, anonymous mappings are widely used by modern allocators to obtain large regions of virtual memory from the operating system.

4. Block

Applications rarely request memory in page-sized units. Instead, programs request arbitrary numbers of bytes like malloc(24) or malloc(137), while the OS allocates memory in pages (4 KiB). The allocator bridges this difference by subdividing pages into smaller memory blocks.

+-------------------------------------------------------------+
|   Header  |  Data Block  |  Header  |  Data Block  |  Free  |
+-------------------------------------------------------------+

5. Metadata

Raw pages from the OS contain no information about how they're being used. The allocator adds a small metadata header before each allocation so it can track block size, allocation state, and free-list links.

One possible header layout is:

struct BlockHeader {
    size_t size;
    bool free;
    struct BlockHeader *next;
};

┌─────────────────┬───────────────────┬────────────────┐
│ Metadata Header │   User Payload    │ Padding/Align. │
│ (Size, Status)  │ (Returned Pointer)│ (Word Boundary)│
└─────────────────┴───────────────────┴────────────────┘
                  ▲
                  └─ Pointer returned to the application

A standard explicit free-list structure chains these blocks together using pointers embedded within the metadata or the free payload space:

[Header | Next] ---> [Header | Next] ---> [Header | Next]

6. Tracking Free Memory

Once blocks exist, the allocator needs a way to remember which ones are available for reuse. There are many ways to track free memory, but here are the two basic ones:

Method 1: Implicit free list

[H][Used]
[H][Used]
[H][Free]
[H][Used]

Method 2: Explicit free list
Once blocks are freed by the user, we need a tracking mechanism. While an implicit list forces you to hop through every single block (used or free) to find an empty slot, our allocator will implement an Explicit Free List.

By using the next pointer inside our metadata headers, we link only the available blocks together into a dedicated chain:

Free List Head
      │
      ↓
+---------+     +---------+     +---------+
| Header  | --> | Header  | --> | Header  |
|  Free   |     |  Free   |     |  Free   |
+---------+     +---------+     +---------+

When a request comes in, we can jump sequentially through this list using search strategies like First-Fit (take the first block that fits) or Best-Fit (find the block closest in size) to find a home for the data.

7. Alignment

Many architectures require or strongly prefer naturally aligned accesses. Proper alignment avoids undefined behavior on some systems and improves performance on many others. If a user requests malloc(3), we must round that payload size up to 8 bytes. Ignoring alignment leads to severe performance degradation or outright crashes on strict architectures.

malloc(3)
  ↓
Header
  ↓
Payload rounded to 8 bytes
  ↓
Next allocation begins on an aligned boundary

8. Splitting

If our free list finds a leftover block that is 256 bytes large, but the user only requested malloc(64), we shouldn't waste the remaining space. We split the block: carving out the requested space, stamping a new metadata header on the remaining 192 bytes, and throwing that remnant back into the free list.

         +----------------------------------+
(Before) |          Free 256 bytes          |
         +----------------------------------+
                         ↓
          Need 64 bytes (malloc(64))
                         ↓
        +----------------+-----------------+
(After) | Head | 64 Used | Head | 192 free |
        +----------------+-----------------+

9. Coalescing

Splitting memory introduces a new issue: external fragmentation. If we free a 64-byte block right next to a 192-byte free block, we technically have 256 bytes of contiguous space. However, if our allocator looks at them as two isolated items, a subsequent request for 200 bytes will fail.

When a block is freed, the allocator checks whether the immediately adjacent blocks in memory are also free. If they are, it coalesces them, merging their boundaries into a single large bloc

Basically this:

         +-----------+-----------+-----------+-----------+
(Before) | H  | Used | H  |Free  | H  |Free  | H  | Used |
         +-----------+-----------+-----------+-----------+
                                 ↓
         +-----------+-----------------------+-----------+
(After)  | H  | Used | H  | Large Free Block | H  | Used |
         +-----------+-----------------------+-----------+

What's Next?

The design is now in place.

The allocator has a defined architecture, a platform abstraction layer, and a clear strategy for obtaining and managing memory. The next step is to replace diagrams with code.

In Part 2, I'll implement the operating system abstraction layer by building os_alloc() and os_free() for both Linux and Windows. Once page allocation is working, the allocator itself can begin taking shape—starting with block headers and progressively adding free-list management, splitting, coalescing, and the implementations of malloc(), calloc(), realloc(), and free().

Conclusion

Every memory allocator starts with the same fundamental constraint: the operating system only provides pages of virtual memory. Everything beyond that, block metadata, free lists, alignment, splitting, coalescing, and the standard allocation functions - is an engineering problem built on top of those pages.

This article establishes the design decisions and architecture that will guide the rest of the project. The implementation that follows will build each component incrementally until the allocator becomes a complete, cross-platform implementation of C's dynamic memory allocation API.

If you're interested in following the project as it evolves, the full source code, documentation, and development history are available on GitHub.

Explore the project on GitHub

DEV Community: Rajat Negi

Building malloc from Scratch (Part 2): Bridging Linux, Windows, and Raw CPU Pages

Recapping Part 1

Table of Contents

Step 1: Defining the OS Interface

Step 2: Building the Platform Backends

Linux Backend

Windows Backend

Step 3: Utility Functions

Alignment

Step 4: Testing the Platform Layer

What's Next?

Building malloc from Scratch (Part 1): Architecture & Core Concepts

Table Of Contents

Project Overview

Design Decisions

#1: Why I am Skipping `sbrk`

#2: Scope

Architecture and Platform Abstraction

Mental Model to Keep

Project Directory Structure

OS Abstraction Layer

Modern Allocator Strategies

Core Concept

1. Virtual Memory

2. Pages

3. Anonymous Mapping

4. Block

5. Metadata

6. Tracking Free Memory

7. Alignment

8. Splitting

9. Coalescing

What's Next?

Conclusion

DEV Community: Rajat Negi

Building malloc from Scratch (Part 2): Bridging Linux, Windows, and Raw CPU Pages

Recapping Part 1

Table of Contents

Step 1: Defining the OS Interface

Step 2: Building the Platform Backends

Linux Backend

Windows Backend

Step 3: Utility Functions

Alignment

Step 4: Testing the Platform Layer

What's Next?

Building malloc from Scratch (Part 1): Architecture & Core Concepts

Table Of Contents

Project Overview

Design Decisions

#1: Why I am Skipping sbrk

#2: Scope

Architecture and Platform Abstraction

Mental Model to Keep

Project Directory Structure

OS Abstraction Layer

Modern Allocator Strategies

Core Concept

1. Virtual Memory

2. Pages

3. Anonymous Mapping

4. Block

5. Metadata

6. Tracking Free Memory

7. Alignment

8. Splitting

9. Coalescing

What's Next?

Conclusion

#1: Why I am Skipping `sbrk`