0x1eaf

Social Media Preview Images

2026-02-13T17:05:27Z

I think they're looking quite good :3

Credit to this post on a blog called Chobble for providing a baseline.

Here it is!

2025 Computer Science Self-Study in Review

2025-12-26T18:30:00Z

It didn't always feel like it, but 2025 was overall a pretty good year in terms of self-study. Despite a slump that lasted roughly four months, I honestly think I made a lot of progress, and it almost feels a bit weird to look back at. I didn't quite finish everything I had planned to, but that's ok. What it all comes down to is, the pace I was going at, coupled with a full-time job, was probably not sustainable, and I really needed that break. And then, once I got back into a good routine, it was all smooth sailing again. So let's have a look at what I've done this year:

Discrete Mathematics by Epp, S.: ✅ Completed
Introduction to Computer Systems by CMU: ✅ Completed
Stanford Online Algorithms Specialization: ⏩ In-progress, part 2/4
Operating Systems: Three Easy Pieces: ⏩ In-progress, chapter 3?/44

Discrete Mathematics

Link

'tis but a distant memory at this point. At least it feels like it. Finishing Epp was a long time coming, but I'm really glad I made it. It bears repeating that this book taught me how to enjoy math. It does an excellent job building up a mathematical foundation for CS students.

I really appreciate that this book starts out with formal logic before anything else. It really forms the building blocks of how to think about math, which turns out to be very important once you reach the subject of algorithms.

One of the final chapters is on the subject of the analysis of algorithms. I think many would consider it extracurricular, especially since a dedicated algorithms course will go much deeper into the subject, but I decided to do it nonetheless, and it's been very beneficial. It spends a lot of time on the mathematical background to the analysis of algorithms. I wrote a lot of proofs about certain functions being or not being at least or at most in the order of some other function and it gave me a strong mental model of how to reason about that notation later. Highly recommend.

Introduction to Computer Systems

Link

In my last year in review I had yet to do the malloc-lab, which I'd eventually write about in this blog post. Yet somehow I missed the most important lesson of all, which it turns out is not "learning how malloc works under the hood provides a strong mental model for how to use malloc". That's a good lesson to learn for sure, but the more important lesson is that I know how to write custom memory allocators now, and I use them all the time. It's called arena allocators, and they're essentially custom memory allocators over blocks of memory that were allocated from the system memory allocator.

The starting code for the malloc lab is something called a "bump-allocator". It just has a pointer and a maximum. It allocates by increasing the pointer and returning its previous address. If it reaches the maximum, it fails. The way it's presented is sort of tongue-in-cheek "this isn't very useful now, is it?". And yet. It turns out, if you have some function that does a bunch of allocations, and you know at runtime that it's gonna use at most X amount of memory, instead of dealing with all these different lifetimes of all these different pointers that you have to individually free when you're done with them and you absolutely can't free them *before you're done with them, and lord help you if you free it twice, instead of all that, what if you just had this one block of memory with a single lifetime, and you slice it up as you need it, and when you're finally done with it, you free it once. It turns out, this sort of thing happens a lot in C programming, and it turns out that a bump-allocator is incredibly useful for this use case in particular. As a result, I've made a lot of bump-allocators, especially in my algorithms course, which I decided to do in C because i'm Like That.

There's a lot more to talk about with regards to this course. It made me a better programmer in many ways, and it has made OSTEP much much easier to work through.

Stanford Online Algorithms Specialization

Link

Algorithms is one of those things that are on my List of Things Every Programmer Should Know. This course definitely isn't the easiest introduction to the subject, but on the other hand it provides some very strong fundamentals in how to reason about algorithms. I was doing this course at a pretty quick pace, finishing part 1 and part 2 in about 4-5 weeks each, before I hit my slump. I'm pretty excited about starting part 3 after OSTEP, but I think I need to do one thing at a time right now.

This is primarily a math course, and more specifically a proof-based course. It's proofs of correctness and proofs of runtime-analysis all the way down, rounding off with a little programming problem at the end of each section, which roughly boils down to "implement this pseudocode and run it against the test cases".

I chose C for the programming problems for one reason primarily: C doesn't give you a lot of things for free, so if you want, say, a hash table, you need to bring your own hash table. As a result, I've implemented all sorts of data structures, from index-based priority queues and binary trees to adjacency list graphs and, yes, hash tables, all from scratch, so I could use them in various algorithms. It's all about learning the internals to strengthen that mental model.

The computer systems course, and in particular the deeper understanding of memory that follows, has been incredibly useful here. A lot of times I've found myself scanning the input to determine exactly how much memory and then allocating exactly that amount of memory for my data structure. Very cool stuff!

I purchased the Algorithms Illuminated book by the course author some 2 years ago, and I've been using it as my primary resource for the course. It's pretty cheap for a university textbook, and very worth it. It's a lot more detailed with the math compared to the video lectures, in my opinion.

Operating Systems: Three Easy Pieces

Link

Unlike the algorithms course, this might just be the easiest introduction to the subject you'll find. Not because it doesn't get difficult (it does), but moreso because Remzi and Andrea (most people seem to forget that there are two authors of this book) are really good at building you from the ground up to be able to handle that difficulty. This makes it very well-suited for self-study, and they made all of that available for free!

This book is split into three main "parts" (or "easy pieces" as it were): virtualization, concurrency, and persistence. As of writing I have just finished the concurrency piece. The neat thing is, it explains things both from the client-side (what does a program need an operating system to do and why?) and from the OS side (how does an operating system implement that?). While the part on virtualization mostly built upon the things I had already learned from computer systems, the concurrency part has been a boon. It goes very deep into the weeds of how concurrency and threads work, how the POSIX threads API works(!), and what sort of concurrency primitives are needed (mostly locks and condition variables), not to mention how to use them to build various concurrent structures like a bounded consumer/producer queue (very useful). There are very few programs worth doing that don't involve concurrency in some manner, and having a good understanding of how that works is pretty essential in my opinion.

With the OSTEP book and lectures there are also projects available to tie all these concepts together. I decided to do the same set of projects that were assigned to the Spring 2018 class at University of Wisconsin-Madison. Much like the book, there are projects focused on the client-side (make a program that uses these OS features), and projects that are essentially kernel hacking projects that have you implement some feature into the xv6 operating system.

One thing about the kernel hacking projects that I hadn't thought about before I did them, but which I think might be a seriously underrated aspect of them is that they give the student some real experience working with a fairly substantial existing code base in order to implement a feature without breaking anything else. This is something that most CS graduates will be doing when they start working in the field, and more importantly, this is not something CS students get a lot of experience with during school. This alone is a good reason for anyone to do at least some of these projects.

So what did we learn

It would appear that learning how to not get to the point where I have to force myself to relax will always be a challenge. This time it resulted in a four month break. The alternative might just have been burnout. The problem, it seems, is that once I get fixated on something, I can't let it go. It's just how my brain works. I need to find another relaxing video game to play when I get like that, I think.

At some point during the year I had made it my goal to finish OSTEP, Algorithms, and Computer Networking by the end of the year. Alas, the slump ensured that wasn't going to happened, but I think that's ok. After all, I made a lot of progress regardless, and there's always next year. As long as I keep putting one food in front of the other, that's all that really matters.

Looking ahead

With concurrency being (most likely) the longest and most difficult part of OSTEP, that course is nearing its end. After that I'll finish up Algorithms, but then what?

There's one subject that I am absolutely certain I will study, which is Computer Networking. The plan is to use course materials based on the free online textbook Computer Networks: A Systems Approach. It's just such a natural progression from all the systems-level programming I've done so far, and as you might be able to tell, I like learning how things work under the hood.

Another thing I've considered is the Database Systems course from CMU (they really like skulls on this one), another systems based course. This one has you implement things in a database using C++! I bet there's gonna be a lot of concurrency in this one.

And finally, I've taken an interest in computing history and I'd love to learn more. It's a bit of a detour from computer science, but I'd say it's still relevant, and history is important!

The Case of the Missing Race Condition

2025-12-16T20:00:00Z

One of the more interesting programming projects for the OSTEP book is the xv6 Kernel Threads project, which has you implement actual multi-threading support for user-level programs in the xv6 kernel, as well as a small library to support it, locks and all. From my understanding, this is a very popular type of lab for university courses in Operating Systems, and it is certainly a great project for learning the low-level building blocks of concurrent programming.

Unfortunately, no test code for this project has been released yet, so if you're doing this project on your own, and you want to verify the correctness of your work (which you should), then you have to write your own.

Given the problem statement, it's actually quite straightforward to figure what needs to be verified and how:

the clone syscall creates a new thread that runs the code at the supplied address
the new thread shares its memory address space with its parent
the provided stack address is the same that gets returned from the corresponding join
the lock provides mutual exclusion and protects against race conditions

For statements 1 through 3, the verification process requires little more than setting variables and comparing them after a join. Easy.

The 4th statement is where it gets tricky. Race conditions, as it turns out, can be notoriously tricky to trigger, as they often have critical sections (sections within which interleaving becomes a problem) that are just a few instructions in length.

Not to worry, I have just the thing: one of the most commonly used introductory examples of a data-race is the concurrent loop-counter. Simply run count++ in a loop, in multiple concurrent threads, where count is a shared variable. Just make sure to mark it volatile, so the compiler doesn't trick you with a mov $count_addr %eax, add $loop_count %eax, mov %eax $count_addr.

Whenever I've run these examples natively, it has never taken more than a count of a few thousand across 2-4 threads to get a final count that's totally wrong, especially on a multi-core CPU. So surely, it shouldn't be too hard to make the same thing happen inside xv6, right?

So that's the idea. Have some piece of code that definitely triggers the race-condition, and then have the same piece of code, but use a lock to protect against the race condition, and verify that it has been resolved.

The test code for triggering the race-condition is dead simple, of course:


void
counter(void *arg1, void *arg2)
{
  for (int i = 0; i < LOOPS; i++) {
    count++;
  }
  exit();
}

/* ---- ... ---- */

/* --- main --- */
  printf(1, "counter: [loops=%d threads=%d expected=%d]\n", LOOPS, THREADS, LOOPS * THREADS);
  printf(1, "counting without locks\n");
  printf(1, "starting count...\n");
  count = 0;
  int spawned[THREADS];
  int joined[THREADS];
  for (int i = 0; i < THREADS; i++) {
    spawned[i] = Thread_create(counter, (void *)i, (void *)0);
  }
  for (int i = 0; i < THREADS; i++) {
    joined[i] = Thread_join();
  }
  printf(1, "\nspawned: [ ");
  for (int i = 0; i < THREADS; i++) {
    printf(1, "%d ", spawned[i]);
  }
  printf(1, "]\n");
  printf(1, "joined:  [ ");
  for (int i = 0; i < THREADS; i++) {
    printf(1, "%d ", joined[i]);
  }
  printf(1, "]\n");
  printf(1, "count: %d\n", count);
  if (count == 0) {
    printf(1, "FAILURE: threads never started\n");
    exit();
  } else if (count != THREADS * LOOPS) {
    printf(1, "race condition! (this is ok)\n");
  } else {
    printf(1, "no race condition? odd...\n");
    printf(1, "not a critical failure, but might indicate a problem with the thread implementation\n");
  }

counter: [loops=500000000 threads=4 expected=2000000000]
counting without locks
starting count...

spawned: [ 8 9 10 11 ]
joined:  [ 9 11 10 8 ]
count: 2000000000
no race condition? odd...

Oh no.

So what's happening here? Did I do something wrong when implementing threads? Set up the stack wrong? Sharing registers? Well, those things would cause things to go wrong in entirely different, and far more dramatic ways than simply "the count isn't wrong and it's supposed to be wrong".

Maybe it's the scheduler! Maybe the thread somehow runs to completion before it ever gets interrupted, thus never triggering the race condition!

I tried so many things. I added print-statements in the scheduler to see if the threads got scheduled more than once (they did), I tried using up to 32 threads, I tried adding CPU's to QEMU, I tried using arrays of count-variables to increase the likelyhood of bad interrupts, I even modified the code that sets the timer interrupt vectors in order to reduce the timer and increase the amount of interrupts, but all that accomplished was slowing down the operating system.

I chalked it up to quirks of the emulation (Professor Remzi appears to agree), and decided on a new approach: printf.

As it turns out, xv6-printf is not thread-safe. That makes sense, why would there be user-level thread-safety with no support for, well, threads? But it gets even better. It turns out, that for every printed character, printf invokes a write-syscall of 1 byte, causing an interrupt. What this means for our testing is, if we use printf in multiple concurrent threads, we get a critical section of code with guaranteed interrupts. That is exactly what is needed.

I made three simple routines. One with no lock, one which locks for the whole loop, and one which locks for each call to printf:

void
print_no_lock(void *arg1, void *arg2) {
    int id = (int)arg1;
    for (int i = 0; i < 5; i++) {
        printf(1, "[%d] print %d\n", id, i);
    }
    exit();
}
void
print_coarse_grained(void *arg1, void *arg2) {
    int id = (int)arg1;
    lock_t *lock = (lock_t *)arg2;
    lock_acquire(lock);
    for (int i = 0; i < 5; i++) {
        printf(1, "[%d] print %d\n", id, i);
    }
    lock_release(lock);
    exit();
}

void
print_fine_grained(void *arg1, void *arg2) {
    int id = (int)arg1;
    lock_t *lock = (lock_t *)arg2;
    for (int i = 0; i < 5; i++) {
        lock_acquire(lock);
        printf(1, "[%d] print %d\n", id, i);
        lock_release(lock);
    }
    exit();
}

And let's see those results:

First, print without locking
[0] print 0
[0] print 1
...
[1] [2] print 0
pri[nt[2] 3] print 0
[3] print 1
...
[2] print 4
Print coarsely grained with an initialized lock (lines may not interleave between threads)
[0] print 0
[0] print 1
[0] print 2
[0] print 3
[0] print 4
...
[3] print 4
Finally print finely grained (lines may interleave between threads, but no line may be garbled)
[0] print 0
[0] print 1
[1] print 0
[2] print 0
[3] print 0
[0] print 2
...
[3] print 4
DONE!

Perfect! And the lock works too!

Running and debugging xv6 for OSTEP in a Docker container

2025-07-07T09:00:00Z

Operating Systems: Three Easy Pieces by Remzi and Andrea Arpaci-Dusseau is a free online textbook, that teaches fundamental operating system concepts. It's a great read (at least it has been so far), written in a very approachable style. As a companion to the textbook, Remzi has published several programming projects, many of which involve hacking on xv6, a minimal teaching operating system based on UNIX, developed by MIT.

The issue you might encounter, if you try to do these projects, is that the version of xv6 used in OSTEP is the x86-version of xv6, which was discontinued in 2018 after MIT decided to move the xv6 project over to RISC-V. While you might be able to build the project on a modern machine by disabling the -Werror compiler flag, running it in QEMU may be a different story, at least out of the box. On my machine running Arch Linux, QEMU hangs with the following message:

SeaBIOS (version Arch Linux 1.16.3-1-1)


iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+1EFD3360+1EF33360 C900
                                                                               


Booting from Hard Disk..

No good.

Fortunately, it's fairly easy to set up and environment that is of the era (circa 2018), using either virtual machines or containerization.

Because I like to stay in the terminal as much as possible, and because the xv6 Makefile includes targets for running QEMU without a GUI, I decided to go with a Docker container based on Ubuntu 18.04, which is the LTS version of the time. In order to run the projects, you need various build tools included in the build-essentials package, as well as QEMU (obviously), gawk, GDB for debugging, and finally expect, which is used by the project testing script:

FROM ubuntu:18.04

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get -yq update && apt-get -yq install --no-install-recommends \ 
    build-essential qemu gawk expect gdb

The DEBIAN_FRONTEND variable is necessary to avoid the package manager asking for user input during install. Save that file with the name "Dockerfile".

Now go ahead and build that image, and give it a nice descriptive name such as, say, "xv6-dev" by running the following command in the same directory as your Dockerfile:

docker build -t xv6-dev .

With that, we now have an image that we can use to build, run, and even debug xv6 in QEMU.

So how do I use this thing?

Obviously a container image is no good if you don't know how to use it. Here's how.

First, let's assume you're working on a project such as initial-xv6, and you've checked out the xv6 repo into a directory named "src":

#inside the initial-xv6 directory
git clone https://github.com/mit-pdos/xv6-public.git src

In that case, navigate to the src directory and run the following:

docker run --rm -it -v $(pwd):/xv6 --workdir /xv6 -p "25000:25000" xv6-dev /bin/bash

A quick explanation of the command line arguments:

--rm: removes the container after it stops
-it: let's you interact with a terminal inside the container
-v $(pwd):/xv6: mounts the present working directory to /xv6 inside the container
--workdir /xv6: sets the present working directory of the container to /xv6
-p "25000:25000": maps port 25000 of the host to port 25000 of the container. Now you should be ready to build, run, and debug.

Building, running, and debugging xv6

The xv6 Makefile defines several targets for not just building but also running the project inside QEMU, including targets with "nox" (for "No X (Server)") in their name, which are used for non-graphical environments. Our Docker container is a non-graphical environment, so that's perfect!

The eagle-eyed will have noticed that we expose port 25000 on the Docker container and wonder why. That is because the gdb-targets in the Makefile start a gdbserver listening on port 25000, which you can use to remotely debug the kernel using gdb on your host OS.

Running xv6 inside QEMU is as simple as running the following command:

make qemu-nox

You know it's working if you see the following prompt:

xv6...
cpu1: starting 1
cpu0: starting 0
sb: size 1000 nblocks 941 ninodes 200 nlog 30 logstart 2 inodestart 32 bmap start 58
init: starting sh
$

Debugging is a bit more involved, but not that difficult. Inside the container run the following:

make qemu-nox-gdb

Your output should look a lot like this:

sed "s/localhost:1234/localhost:25000/" < .gdbinit.tmpl > .gdbinit
*** Now run 'gdb'.
qemu-system-i386 -nographic -drive file=fs.img,index=1,media=disk,format=raw -drive file=xv6.img,index=0,media=disk,format=raw -smp 2 -m 512  -S -gdb tcp::25000

Now on your host OS, navigate to the same src folder that xv6 is in, and run:

gdb kernel

Inside gdb, run target remote localhost:25000. This will connect your gdb client to the gdbserver that's running inside the container. Go ahead and set a breakpoint in main continuing execution. It should stop right at the beginning of main:

(gdb) target remote localhost:25000
Remote debugging using localhost:25000
0x0000fff0 in ?? ()
(gdb) break main
Breakpoint 1 at 0x80102ea0: file main.c, line 19.
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, main () at main.c:19
19	{
(gdb)

And there you have it. You are now ready to debug your kernel hacking shenanigans.

What I learned from re-implementing Malloc

2025-02-01T20:00:00Z

What's in an allocator

A dynamic memory allocator is primarily used for three things:

To allocate memory whose size is not known at compile-time
To allocate very large blocks of memory
To allocate memory whose lifetime needs to be longer than the scope of the function that allocates it.

A general-purpose allocator like malloc really has the following main requirements, many of which are in conflict with each other:

Allocation must be very fast.
The allocator must utilize memory efficiently. This means reducing fragmentation and overhead.
Memory must be contiguous. If an application asks for a block of a certain size, then that block must be a single block of memory. It cannot be split up.
Once a memory block has been allocated, its address cannot be moved unless the application explicitly asks to have it reallocated.
Requests for allocation and freeing of memory can come in in any order, and the allocator cannot reorder them. If a request is received. it is immediately serviced.
The memory allocator can expect that each allocation request will have a corresponding deallocation request.

The presents an interesting balancing act where the need maximize memory utilization may introduce extra performance overhead, and vice versa. Since live blocks of memory cannot be moved, consolidation of memory blocks can only happen on free blocks of memory. If there are many small fragments of free memory in-between live blocks, too bad, you have to wait until one of those blocks gets freed.

We are given some leeway with the last requirement, however, and that is that it is the responsibility of the application to make sure that memory doesn't leak, that all deallocation requests are valid, and that free memory is never accessed. This means, that the allocator does not need to concern itself with any of those things.

The malloc API

The allocator API that we are going to implement is very simple:

size_t mm_init(void);
void *mm_malloc(size_t size);
void mm_free(void *ptr);
void *mm_realloc(void *ptr, size_t new_size);

Each function has the following contracts:

mm_init: Initialize the memory allocator. Return 0 on success, and -1 on failure.
mm_malloc: Return a pointer to a memory block that is at least size big, or NULL if the request fails. size cannot be 0.
mm_free: Deallocate the block of memory starting at the address of ptr. ptr must be the starting address of an allocated block of memory.
mm_realloc: Return a pointer to a block of memory that is at least new_size big. The data at the returned pointer must be identical to the data at ptr up to the new_size'th byte.

To support our implementation, we're given the mem_sbrk function as an analogue to sbrk. This function simply increases the heap by the requested size, and returns the base address of the new area. This way, the autograder that is included in the lab can keep track of where memory is allocated on the heap, and inspect it for measuring the correctness and performance of the allocator.

How is this thing scored

As mentioned, the malloc-lab includes an autograder that is used to inspect the behavior of the memory allocator in order to measure its correctness and performance. It scores the allocator on three metrics:

Correctness: a faulty allocator gets 0 points.
Utilization: How much memory is in use vs how much memory was requested (0 points for 0%, 60 points for 100%).
Throughput: How fast is my memory allocator compared to libc (40 points, if it's at least as fast).

By default, the autograder is configured to compare the throughput of my allocator against a hardcoded value of 600Kops/sec (where each "op" represents a call to malloc, free, and realloc). This is a comically low number on a modern machine. Luckily a commandline option to measure the performance of libc malloc on my own machine, which comes out to ~30,000Kops/sec, which is the value that I will use.

Implicit free-list - the textbook implementation

The first implementation is a simple implicit free-list implementation that is mostly copied over from the CS:APP textbook, with all the macros replaced with inline functions and constexpr values. As a result, this section will mostly be a retread of that section in the textbook.

Each block of memory contains a header and a footer with the payload in the middle.

The header and the footer both encode the size of their block, thus implicitly linking each block together via simple pointer arithmetic starting from the base of the first block of memory.

Due to alignment requirements, each block of memory has to start at an address that is a multiple of either 4 or 8 (depending on whether it's a 32- or 64-bit platform). As a result, the 2 or 3 least significant bits are guaranteed to be zero. We can take advantage of that to encode information about the block in the header as well as the size. We will use the least significant bit to encode whether the block has been allocated or not.

To implement this, let's first define some simple utility functions and constants.

get_size: returns the size-field from a header or footer.
get_alloc: returns the alloc-field from a header or footer.
put: assigns a value to a header or footer.
pack: returns the bitwise or of two unsigned integers (used to pack the size-field with the alloc field).
header: returns the header pointer from a block pointer
footer: returns a footer pointer from a block pointer
next_block_pointer: returns the next block pointer from the current one.
prev_block_pointer: returns the previous block pointer from the current one.

From this we can start constructing our allocator. We start with the init function.

int mm_init(void) {
    if ((heap_listp = mem_sbrk(4 * w_size)) == (void *)-1)
        return -1;
    // padding
    put(heap_listp, 0);

    //prologue headers
    put(heap_listp + w_size, pack(d_size, 1));
    put(heap_listp + (2 * w_size), pack(d_size, 1));

    //epilogue header
    //this gets overwritten when the heap is extended
    put(heap_listp + (3 * w_size), pack(0, 1));

    //set the base of the heap to be at the prologue
    heap_listp += (2 * w_size);

    if (extend_heap(chunk_size) == NULL)
        return -1;

    return 0;
}

We create an initial heap with a total of 4 32-bit words. The first word is padding to keep the heap aligned to 8 bytes, while the prologue headers create an "allocated" block that points to the epilogue block which terminates the list. At this point, the heap is ready to use, however, with no free blocks, it's perhaps not the most useful heap in the world, so let's extend it.

static void *extend_heap(size_t size) {
    //align the size to 8 bytes
    size = ((size - 1) | 0x7) + 1;
    char *bp;
    if ((long)(bp = mem_sbrk(size)) == -1)
        return NULL;
    //create the new free block
    //overwriting the previous epilogue
    put(header(bp), pack(size, 0));
    put(footer(bp), pack(size, 0));

    //create new epilogue
    put(header(next_block_pointer(bp)), pack(0, 1));

    return coalesce(bp);
}

We overwrite the epilogue with a new header specifying a free block of the size of the extension. Because it's not unlikely that this new free block comes after another free block, we also choose to coalesce it, that is, combine any neighboring free blocks into one single block.

static void *coalesce(char *bp) {
    // Is the previous block allocated?
    size_t prev_alloc = get_alloc(footer(prev_block_pointer(bp)));
    // Is the next block allocated?
    size_t next_alloc = get_alloc(header(next_block_pointer(bp)));

    size_t size = get_size(header(bp));

    if (prev_alloc && next_alloc)
        /*
         * Case 1:
         * No neighbouring block is free. Do not coalesce.
         * Return the same pointer
         */
        return bp;
    else if (prev_alloc && !next_alloc) {
        /*
         * Case 2:
         * The preceding block is not free, but the succeeding
         * one is. Add the size of that block to the current size,
         * encode it in the header of the current block, and return
         * its pointer.
         */
        size += get_size(header(next_block_pointer(bp)));
        put(header(bp), pack(size, 0));
        put(footer(bp), pack(size, 0));
    } else if (!prev_alloc && next_alloc) {
        /*
         * Case 3:
         * The preceding block is free, but the succeeding
         * block is not. Add the size of the the preceeding block
         * to the size, encode it in the header of the preceeding block
         * and return a pointer to that block.
         */
        size += get_size(footer(prev_block_pointer(bp)));
        put(footer(bp), pack(size, 0));
        put(header(prev_block_pointer(bp)), pack(size, 0));
        bp = prev_block_pointer(bp);
    } else {
        /*
         * Case 4:
         * Both neighboring blocks are free. Add
         * the sizes of all three blocks together and encode
         * it in the header of the preceeding block. Return
         * a pointer to that block.
         */
        size += get_size(footer(prev_block_pointer(bp))) +
                get_size(header(next_block_pointer(bp)));
        put(header(prev_block_pointer(bp)), pack(size, 0));
        put(footer(next_block_pointer(bp)), pack(size, 0));
        bp = prev_block_pointer(bp);
    }

    return bp;
}

Now let's look at how we actually allocate memory.

void *mm_malloc(size_t size) {
    size_t adj_size;
    size_t ext_size;
    char *bp;

    // 0 is not a valid size.
    if (size == 0) {
        return NULL;
    }

    // Calculate the effective size of the block.
    // The block must be at least the size two headers
    // plus and an 8 byte word.
    // The total payload will be at least 8 bytes larger than
    // the requested size to acommodate the header and the footer
    if (size <= d_size) {
        adj_size = 2 * d_size;
    } else {
        adj_size = d_size * ((size + (d_size) + (d_size - 1)) / d_size);
    }

    // Find a block of memory to satisfy the request.
    if ((bp = find_fit(adj_size)) != NULL) {
        //Allocate the block
        place(bp, adj_size);
        return bp;
    }

    //If no block is found, extend the heap. If extending the heap
    //fails, the allocation fails
    ext_size = max(adj_size, chunk_size);
    if ((bp = extend_heap(ext_size)) == NULL) {
        return NULL;
    }
    //Allocate to the new block.
    //Since we extended the heap by at least the amount
    //needed to satisfy the request, it is a guaranteed fit.
    place(bp, adj_size);
    return bp;
}

Now is a good time to talk about fit-policies. There are many different strategies to take when it comes to finding an appropriate block of memory to allocate (a fit). There are three popular ones:

First fit: Search the whole list from the beginning of the free-list. Select the first available block that can satisfy the request.
Next fit: Like first fit, but instead of starting from the beginning, start from where the last search left off.
Best fit: Search the entire free-list and select the block that is closest in size to the requested size. Short-circuit on an exact match. On the surface, this looks like a simple trade-off between throughput and utilization. Pick first fit for throughput, and best-fit for utilization. It is not so simple, however. The issue with a best-fit policy is that, paradoxically, a fit can be too good without being perfect, depending on the allocator's splitting policy. As a result, the allocator may split off many small blocks of memory, that are too small to satisfy any request, and all but contribute to fragmentation. For this allocator, we choose a first-fit policy because it is the simplest.

static void *find_fit(size_t size) {
    for (char *bp = heap_listp;
         get_size(header(bp)) > 0;
         bp = next_block_pointer(bp)
    ) {
        if (!get_alloc(header(bp)) && (size <= get_size(header(bp)))) {
            return bp;
        }
    }
    return NULL;
}

This one is very simple. Just iterate through each block on the list. If a block is not allocated, and its size is large enough, allocate it. If no block is found, return NULL.

Next comes placement.

static void place(void *bp, size_t size) {
    size_t csize = get_size(header(bp));
    //if the split block is at least as large
    //as the minimum block size
    if ((csize - size) >= (2 * d_size)) {
        //split
        put(header(bp), pack(size, 1));
        put(footer(bp), pack(size, 1));
        bp = next_block_pointer(bp);
        put(header(bp), pack(csize - size, 0));
        put(footer(bp), pack(csize - size, 0));
    } else {
        //else do not split and simply mark as allocated
        put(header(bp), pack(csize, 1));
        put(footer(bp), pack(csize, 1));
    }
}

First, we have to decide on whether or not to split the block in two. For this implementation we simply check, if the split block would be at least large enough to hold the minimum block size, and if it is, split it.

By setting the alloc-bit to one, we have marked it as allocated, and the malloc-function can safely return a pointer to the block.

Freeing memory in this kind of allocator is very simple:

void mm_free(void *bp) {
    size_t size = get_size(header(bp));

    put(header(bp), pack(size, 0));
    put(footer(bp), pack(size, 0));
    coalesce(bp);
}

Just mark the block as free and coalesce.

Finally we have realloc. This one is actually just the default implementation included in the lab:

void *mm_realloc(void *bp, size_t size) {
    void *oldptr = bp;
    void *newptr;
    size_t copy_size;

    newptr = mm_malloc(size);
    if (newptr == NULL)
        return NULL;
    copy_size = get_size(header(oldptr)) - d_size;
    if (size < copy_size)
        copy_size = size;
    memcpy(newptr, oldptr, copy_size);
    mm_free(oldptr);
    return newptr;
}

This implementation simply makes a call to malloc for a block of the new size, uses memcpy to copy the data of the old block over to the new block, and frees the old block.

With that, we have a fully functional memory allocator. Let's see how it performs.

Results for mm malloc:
trace  valid  util     ops      secs  Kops/sec
 0       yes   99%    5694  0.003271  1741
 1       yes   98%    5848  0.003519  1662
 2       yes   99%    6648  0.004608  1443
 3       yes   99%    5380  0.003373  1595
 4       yes   20%   14400  0.000059242424
 5       yes   91%    4800  0.004205  1142
 6       yes   92%    4800  0.003832  1252
 7       yes   55%   12000  0.067335   178
 8       yes   51%   24000  0.110799   217
 9       yes   21%   14401  0.025789   558
10       yes   23%   14401  0.000938 15348
Total          68%  112372  0.227729   493

Perf index = 41 (util) + 1 (thru) = 41/100

While memory utilization isn't disastrous, the throughput here is abysmal, coming in at around ~1.5% of the throughput of libc malloc. So why is that?

Freeing is obviously very fast, both the free and coalesce operations are constant-time involving only addition and bit-flipping.

Allocation on the other hand involves a linear search, not just of the free list (there is no free-list to be quite honest), but of the entire implicit list of every block of memory known to the allocator. Not only is this slow by default, but it will get slower and slower as the heap grows.

We can do better.

Second iteration: explicit free-list

Since free-blocks are, well, free, we're allowed to put any data we want in them. Thus we can make our free-list data structure explicit by including pointers to the previous and next free memory blocks, creating a doubly-linked list.

(For simplicity's sake, the free-list has been rendered with double-sided arrows, but in practice, every pointer is the address of the base of the block that it points to. So both next and previous point to the previous-field of the next and previous node in the list respectively.)

As illustrated, one consequence of this is that the free-list is no longer ordered by continuously by their address. There are explicit free-list implementations that are address-ordered (and literature suggests that they are good at reducing fragmentation), however, we are only going to consider two policies for our allocator:

First in, first out (FIFO): Each new free block is appended to the tail of the list. The free-list is searched from the head, so the least recently freed block that fits will be allocated for a given request.
Last in, first out (LIFO): Each new free block is prepended to the head of the list. The free-list is search from the head, so the most recently freed block that fits will be allocated for a given request. In either case it is a standard implementation of a doubly-linked list, so I won't bore you with the details.

Now, it turns out that we only have to make some pretty minor changes to our existing code in order to implement the explicit free-list. Let's look at mm_malloc:

 void *mm_malloc(size_t size) {
...
-    if (size <= d_size) {
-        adj_size = 2 * d_size;
+    if (size <= 3 * w_size) {
+        adj_size = min_block_size;
     } else {
-        adj_size = d_size * ((size + (d_size) + (d_size - 1)) / d_size);
+        adj_size = ((w_size + size - 1) | 0x7) + 1; // size + header
...

Because each free block now needs to hold two pointers, a header, and a footer, the minimum block size has to be increased in order to accommodate one. A constant has been introduced to encode this value. I also decided to change the way that the alignment operation is implemented.

extend_heap and mm_free just need to insert the new free block into the free-list.

static void *extend_heap(size_t size) {
     size = ((size - 1) | 0x7) + 1;
     char *bp;

     if ((long)(bp = mem_sbrk(size)) == -1)
         return NULL;

     put(header(bp), pack(size, 0));
     put(footer(bp), pack(size, 0));
     put(header(next_block_pointer(bp)), pack(0, 1));
+    bp = coalesce(bp);
+    insert_node((free_node_t *)bp);
-    return coalesce(bp);
+    return bp;
 }

 void mm_free(void *bp) {
     size_t size = get_size(header(bp));

     put(header(bp), pack(size, 0));
     put(footer(bp), pack(size, 0));
-    coalesce(bp);
+    bp = coalesce(bp);
+    insert_node(bp);
 }

coalesce is now responsible for removing consolidated blocks from the free list.

 static void *coalesce(char *bp) {
     size_t prev_alloc = get_alloc(footer(prev_block_pointer(bp)));
     size_t next_alloc = get_alloc(header(next_block_pointer(bp)));
     size_t size = get_size(header(bp));

     if (prev_alloc && next_alloc)
         return bp;
     else if (prev_alloc && !next_alloc) {
-        size += get_size(header(next_block_pointer(bp)));
+        char *next_bp = next_block_pointer(bp);
+        size += get_size(header(next_bp));
         put(header(bp), pack(size, 0));
         put(footer(bp), pack(size, 0));
+        free_node_t *neighbour_node = (free_node_t *)next_bp;
+        remove_node(neighbour_node);
     } else if (!prev_alloc && next_alloc) {
-        size += get_size(footer(prev_block_pointer(bp)));
+        char *prev_bp = prev_block_pointer(bp);
+        size += get_size(footer(prev_bp));
+        free_node_t *prev_node = (free_node_t *)prev_bp;
+        remove_node(prev_node);
         put(footer(bp), pack(size, 0));
         put(header(prev_block_pointer(bp)), pack(size, 0));
         bp = prev_block_pointer(bp);
     } else {
-        size += get_size(footer(prev_block_pointer(bp))) +
-                get_size(header(next_block_pointer(bp)));
+        char *next_bp = next_block_pointer(bp);
+        char *prev_bp = prev_block_pointer(bp);
+        size += get_size(footer(prev_bp))
+            + get_size(header(next_bp));
+        free_node_t *prev_node = (free_node_t *)prev_bp;
+        remove_node(prev_node);
         put(header(prev_block_pointer(bp)), pack(size, 0));
         put(footer(next_block_pointer(bp)), pack(size, 0));
+        free_node_t *next_node = (free_node_t *)next_bp;
+        remove_node(next_node);
         bp = prev_block_pointer(bp);
     }

     return bp;
 }

place removes allocated blocks from the free-list, and inserts newly split blocks back into it.

 static void place(void *bp, size_t size) {
     size_t csize = get_size(header(bp));
-    if ((csize - size) >= (2 * d_size)) {
+    if ((csize - size) >= min_block_size) {
         put(header(bp), pack(size, 1));
         put(footer(bp), pack(size, 1));
+        free_node_t *node = (free_node_t *)bp;
+        remove_node(node);
         bp = next_block_pointer(bp);
         put(header(bp), pack(csize - size, 0));
         put(footer(bp), pack(csize - size, 0));
+        free_node_t *new_node = (free_node_t *)bp;
+        insert_node(new_node);
     } else {
         put(header(bp), pack(csize, 1));
         put(footer(bp), pack(csize, 1));
+        free_node_t *node = (free_node_t *)bp;
+        remove_node(node);
     }
 }

An important lesson that I keep having to relearn is keep it working. You can implement all the supporting code for the explicit-free list without touching the implicit free-list code at all. None of the code-changes mentioned so far have actually changed any of the behavior of the code at all except for maintaining this, currently inconsequential, data structure, and increasing the minimum block size by 8 bytes. We're still running a working implicit free-list.

The final code change is to then switch the find_fit function from traversing the list by block size to traversing the linked-list data structure we just implemented.

 static void *find_fit(size_t size) {
-    char *bp;
-    for (bp = heap_listp;
-         get_size(header(bp)) > 0;
-         bp = next_block_pointer(bp)
-    ) {
-        if (!get_alloc(header(bp))
-            && (size <= get_size(header(bp)))
-        ) {
-            heapcheck(__LINE__);
-            return bp;
+    for (free_node_t *node = free_list;
+         node;
+         node = node->next
+    ) {
+        if (size <= get_size(header((char *)node))) {
+            return node;
         }
     }
 }

In reality, I didn't actually do it like that. I made many ill-considered changes that left me with a hard-to-debug broken allocator, and I ran git restore mm.c at least a few times. So let that be a lesson: keep it working.

With the explicit free-list done, let's run the autograder and measure our performance: LIFO:

Results for mm malloc:
trace  valid  util     ops      secs  Kops/sec
 0       yes   89%    5694  0.000093 61160
 1       yes   91%    5848  0.000058100309
 2       yes   94%    6648  0.000160 41524
 3       yes   97%    5380  0.000125 42971
 4       yes   66%   14400  0.000065221880
 5       yes   89%    4800  0.000305 15722
 6       yes   88%    4800  0.000307 15615
 7       yes   55%   12000  0.000988 12143
 8       yes   51%   24000  0.001298 18489
 9       yes   27%   14401  0.025642   562
10       yes   30%   14401  0.001027 14020
Total          71%  112372  0.030070  3737

Perf index = 42 (util) + 5 (thru) = 47/100

FIFO:

Results for mm malloc:
trace  valid  util     ops      secs  Kops/sec
 0       yes   98%    5694  0.000062 92435
 1       yes   96%    5848  0.000065 90667
 2       yes   98%    6648  0.000073 90449
 3       yes   99%    5380  0.000051106324
 4       yes   66%   14400  0.000064224299
 5       yes   92%    4800  0.000741  6474
 6       yes   91%    4800  0.000664  7225
 7       yes   55%   12000  0.007343  1634
 8       yes   51%   24000  0.034446   697
 9       yes   27%   14401  0.026885   536
10       yes   30%   14401  0.001033 13945
Total          73%  112372  0.071427  1573

Perf index = 44 (util) + 2 (thru) = 46/100

Now, while the dramatic difference between the two is somewhat surprising (the fact that the slowest traces are the ones that do the most calls to realloc might be part of the story here), I am not at all surpised that the LIFO version comes out ahead, and the reason for that is locality.

Locality is simply the idea that memory that has been accessed once, will most likely be accessed again, and when one block of memory gets accessed, its neighboring blocks will most likely be accessed too. Thus, code that exhibits high locality, will access the same memory frequently, and access contiguous blocks of memory in sequence. This has performance implications due the way the CPU cache works. Simply put code with good locality will have fewer cache misses, resulting in faster memory access.

Arguably, blocks of memory that have been freed more recently, are also more likely to have been used more recently. As a result, they then more likely to be present in lower (faster) levels of cache memory. Given that LIFO allocates the most recently freed blocks, and FIFO allocates the least recently freed blocks, it would come as a surprise, if LIFO interacts better with the CPU caches and is faster as a result.

This is still a linear search, however. A linear search on a smaller n, but linear nonetheless. We can do better.

But first, it's time to stop cheating

Unfortunately there's a fundamental problem with treating this as a portable, general-purpose allocator, and that is that the header data has been encoded in an unsigned int, which is a 32-bit value on x86 and x64. This is an artifact from following the textbook-implementation from earlier. While this would be totally ok if we restrict ourselves to making an allocator for a 32-bit system, it feels a bit like cheating, because it allows us to pack the headers more closely.

For the autograder, this is no problem, because the autograder's heap is limited to 20MB, a size that fits well within a 32-bit unsigned integer, and thus it has not caused any problems so far. However, this is supposed to be a general-purpose allocator, and it's honestly an interesting exercise to make it work the same on both 32-bit and 64-bit architectures.

size_t is an unsigned integer data type in C used to represent the size of an object. Since an object, in theory, could be as large as the entire virtual address space, size_t needs to be able to accommodate a size that is at least as large (at least, I assume this to be the case, I haven't actually looked that up). As such, size_t is 4 bytes on x86, and 8 bytes on x64. From this point onward, block metadata is represented using a size_t instead of an unsigned int.

Results for mm malloc:
trace  valid  util     ops      secs  Kops
 0       yes   89%    5694  0.000114 49904
 1       yes   92%    5848  0.000070 83782
 2       yes   94%    6648  0.000172 38696
 3       yes   96%    5380  0.000122 43954
 4       yes   66%   14400  0.000084172249
 5       yes   86%    4800  0.000301 15942
 6       yes   85%    4800  0.000278 17266
 7       yes   51%   12000  0.003027  3964
 8       yes   50%   24000  0.001738 13811
 9       yes   26%   14401  0.026118   551
10       yes   38%   14401  0.000971 14831
Total          70%  112372  0.032995  3406

Perf index = 42 (util) + 5 (thru) = 47/100

Only a minor performance hit.

A small optimization that was done in conjunction with this change was removing the footer from allocated blocks, and encoding whether the previous block was allocated in a bit-field in the header. The advantage of doing this is arguably pretty small.

Third iteration: segregated free-list

Let's finally address the linear search of the free-list. What if, instead of searching the entire free-list for a block of appropriate size, we eliminate every block that is guaranteed to be too small, and only search blocks that are either of similar size or larger. This is where the segregated free-list comes in.

The idea is that instead of having just one free-list, we have an array of free-lists, where each list has its own size-class.

By having each size-class be a power of two, we can allocate an array of w_bits pointers to a free list, where w_bits is the number of bits in a size_t. This way, we can calculate the size class of a given node or requested size by taking the floored base 2 logarithm of the given size. Given that the minimum block size is 4, the log base 2 of which is 2, we could in theory eliminate size class 0 and 1 from the array, but we only eliminate size class 0.

All we have to do to our free-list data structure is take the log base 2 of the size to calculate the index into the free-list array, and then insert the node into the correct free-list like before.

Then all we need to do is allocate some extra space on the heap for the array of free-lists and initialize it to 0 in mm_init and update find_fit.

 static void *find_fit(size_t size) {
-    for (free_node_t *node = free_list;
-         node;
-         node = node->next
-    ) {
-        if (size <= get_size(header((char *)node))) {
-            return node;
+    size_t i = log2_of(size) - 1;
+    while (i < w_bits) {
+        for (free_node_t *node = free_lists[i];
+             node;
+             node = node->next
+        ) {
+            if (size <= get_size(header((char *)node))) {
+                return node;
+            }
         }
+        i++;
     }
     return NULL;
 }

(yes, the outer loop could have been a for-loop too)

And that's all there is to it. Let's see how it compares.

Results for mm malloc:
trace  valid  util     ops      secs  Kops
 0       yes   98%    5694  0.000098 57925
 1       yes   97%    5848  0.000111 52590
 2       yes   99%    6648  0.000126 52846
 3       yes   99%    5380  0.000099 54343
 4       yes   65%   14400  0.000198 72691
 5       yes   92%    4800  0.000180 26652
 6       yes   90%    4800  0.000174 27602
 7       yes   55%   12000  0.000163 73620
 8       yes   50%   24000  0.000303 79156
 9       yes   25%   14401  0.026707   539
10       yes   16%   14401  0.001766  8156
Total          71%  112372  0.029926  3755

Perf index = 43 (util) + 5 (thru) = 48/100

At a glance, that looks like a pretty minor improvement, but look at trace 9. What's going on with that?

A second look at `realloc`

Well, trace 9 is called realloc-bal.rep which should give you a hint. Recall that we haven't touched mm_realloc at all so far, and it is a guaranteed call to memcpy, which certainly sounds expensive. So let's try to optimize that.

The requirements state that we only need to return a pointer to block of memory of the requested size with the old data available. It doesn't say it has to be a different pointer, and if we can return the same pointer, than we don't have to memcpy, not to mention the associated calls to mm_malloc and mm_free.

There are two cases we have to care about:

The requested size + header is equal to or less than the currently allocated block size.
The requested size + header is larger than the currently allocated block size.

Case 1 is trivial. We simply return the same pointer and do nothing. We could try to split to create a free block of memory, but that appeared to make utilization worse, not better.

In case 2, we can avoid the reallocation and copying by coalescing with the next block of memory on the condition that it is not already allocated.

 void *mm_realloc(void *bp, size_t size) {
     void *oldptr = bp;

+    size_t block_size = get_size(header(oldptr));
+    if (size + w_size < block_size) {
+        return oldptr;
+    } else if (size < block_size) {
+        size = block_size;
+    }
+
+    char *next_bp = next_block_pointer(bp);
+    size_t next_alloc = get_alloc(header(next_bp));
+    size_t next_size = get_size(header(next_bp));
+    if (!next_alloc && size + w_size <= block_size + next_size) {
+        block_size += next_size;
+        put(header(bp), pack(block_size, 1));
+        remove_node((free_node_t *)next_bp);
+        set_prev_alloc(header(next_block_pointer(bp)), 1);
+        heapcheck(__LINE__);
+        return bp;
+    }
+
     void *newptr = mm_malloc(size);
     if (newptr == NULL)
         return NULL;
-    size_t copy_size = get_size(header(oldptr)) - w_size;
-    if (size < copy_size)
-        copy_size = size;
-    memcpy(newptr, oldptr, copy_size);
     memcpy(newptr, oldptr, block_size);
     mm_free(oldptr);
     return newptr;
 }

Let's see how that performs.

Results for mm malloc:
trace  valid  util     ops      secs  Kops
 0       yes   98%    5694  0.000121 47136
 1       yes   97%    5848  0.000123 47622
 2       yes   99%    6648  0.000148 44858
 3       yes   99%    5380  0.000125 43213
 4       yes   64%   14400  0.000157 91778
 5       yes   92%    4800  0.000199 24169
 6       yes   90%    4800  0.000194 24793
 7       yes   55%   12000  0.000196 61224
 8       yes   50%   24000  0.000339 70734
 9       yes   46%   14401  0.000165 87120
10       yes   66%   14401  0.000123117463
Total          78%  112372  0.001889 59500

Perf index = 47 (util) + 40 (thru) = 87/100

Ok then. I appear to have made a malloc that is twice as fast as libc-malloc.

But that's not really a fair comparison. For one, this implementation is evaluated against a small set of mostly synthetic allocation patterns, which is not necessarily representative of the kinds of allocation patterns a real-world allocator would have to face.

Secondly, my allocator is not thread-safe. If a multi-threaded program were to use my allocator from concurrent threads, disastrous things would likely happen.

And finally, libc-malloc likely does a lot of work to maximize memory utilization that my allocator doesn't do, especially to guard against what one might call pathological allocation patterns. You may notice that while the average memory-utilization of my own allocator is ok, the utilization shown in some of these traces is downright catastrophic. 50% utilization is simply not ok, unless you're allocating single size_t's almost exclusively.

So what did we learn

Arguably the purpose of this exercise is not for me to write my own general-purpose allocator for a general-purpose widely used operating system. I can't write a better allocator than libc, and I don't need to.

However, that doesn't mean it was at all pointless. There are many reasons one might want to learn how to reinvent the wheel. Here are a few:

Learning how to implement a simplified version of malloc, improves my understanding of how to use the malloc that is installed on my operating system. This goes for all things programming in my opinion. If you learn how to build the thing, even if it's a toy version of the thing, you get better at using the real thing. You get a deeper understanding of what its capabilities are, what kinds of things can go wrong, and how to mitigate them.
Sometimes you might actually find yourself needing to write your own memory allocator. This is the case more so in the embedded world than not, but it does also apply to userspace applications running in OS'es like Linux. A common use case that is brought up in the textbook, for instance, is graph data structures, where the program might request a large block of memory from malloc, and then use its own purpose-built allocator to manage allocations within that block.
I gain a deeper understanding of the security implications of memory bugs. It is a well-known fact that memory bugs make up one of the largest classes of security vulnerabilities in the wild. Many of these are related to overflowing string buffers, but a large amount is also related to use-after-free bugs and double-free bugs. Now that I know how memory allocation works under the hood, I have a much stronger mental model of why these things can be security vulnerabilities, and I think that's important too, if I want to be someone writing safe software.

we do a little data wrangling

2025-01-17T16:53:07Z

I wanted to do some rudimentary statistics on the Swedish tech job market, both to test a few hypotheses of mine, and also to get informed about what subject areas I want to focus on in terms of employability. It's no secret that I want a new job doing something else than what I'm doing at my current job, so as much as I want to study for the sake of learning things that make me excited, I also need to stay cognizant of what job qualifications are in demand.

Luckily, the Swedish Employment publishes an open web API which gives access to all job adverts that they have ever hosted on their current platform. So let's get all job adverts that were posted since the beginning of 2024:

❯ curl -H "Content-type: application/json" \
'https://jobstream.api.jobtechdev.se/stream?date=2024-01-01T00:00:00' > jobs.json

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  682M    0  682M    0     0  4473k      0 --:--:--  0:02:36 --:--:-- 5017k
❯

Awesome.

Now, the Linux command line, it turns out, is an excellent too for wrangling large datasets. Let's look at the tools we're gonna use:

cat: simply prints the contents of a file
jq: format, filter, and transform JSON data.
sed: short for "stream-editor". Can do various line-by-line transformations using RegEx. We're just gonna do simple search-replace with it.
sort: it sorts!
uniq: prints and counts unique lines. Requires sorted data.
grep: extract data with RegEx!

The data we get is an array of JSON objects. The fields we're interested in are occupation_group, which denotes the job category, and description, which contains the job description. The occupation_group-field looks like this:

{
  "concept_id": string,
  "label": string,
  "legacy_ams_taxonomy_id": int
}

We're interested in the concept_id for the label "Mjukvaru- och systemutvecklare m.fl." ("Software- and system developers etc.").

As a fun little exercise, let's find the amount of job ads for each category:

❯ cat jobs.json |
jq '.[].occupation_group | select(.label != null) | .label' |
sort | uniq -c | sort -nr
   1879 "Mjukvaru- och systemutvecklare m.fl."
   1637 "Grundutbildade sjuksköterskor"
   1628 "Personliga assistenter"
   1392 "Företagssäljare"
    920 "Undersköterskor, hemtjänst, hemsjukvård, äldreboende och habilitering"
    915 "Motorfordonsmekaniker och fordonsreparatörer"
    ...

So much for the recession in the tech industry, huh.

Enough of that, let's find that ID:

cat jobs.json |
jq '.[].occupation_group | select(.label != null)' |
grep Mjukvaru -B2 -A2
{
  "concept_id": "DJh5_yyF_hEM",
  "label": "Mjukvaru- och systemutvecklare m.fl.",
  "legacy_ams_taxonomy_id": "2512"
}
--
{
  "concept_id": "DJh5_yyF_hEM",
  "label": "Mjukvaru- och systemutvecklare m.fl.",
  "legacy_ams_taxonomy_id": "2512"
}
--
#...

Now we can use that ID to filter for software jobs only, and extracting the formatted text of the advert:

jq '.[] | select(.occupation_group.concept_id == "DJh5_yyF_hEM") | .description.text_formatted'

Make it all lowercase for ease of processing keywords:

 tr '[:upper:]' '[:lower:]'

Remove HTML tags and newlines:

sed 's/\\n//g' | sed -E 's/<\/?[a-z]{1,10}>//g'

Extract all the keywords I'm interested in - programming languages and other qualifications. I use the -P flag to use Perl's RegEx engine, which enables lookahead and lookbehind qualifiers.

grep -oP '\(?<ǃ\w)((c#)|(c)|(java)|(javascript)|(typescript)|(js)|(ts)|(python)|(linux)|(elixir)|(erlang)|(go)|(c\+\+)|(react)|(angular)|(svelte)|(\.net)|(embedded)|(rust)|(scala)|(clojure)|(kotlin)|(ruby)|(swift)|(golang))(?=[ ,./])'

Count the occurrence of each keyword

sort | uniq -c | sort -nr

Putting it all together

❯ cat jobs.json |
jq '.[] | select(.occupation_group.concept_id == "DJh5_yyF_hEM") | .description.text_formatted' |
tr '[:upper:]' '[:lower:]' |
sed 's/\\n//g' | sed -E 's/<\/?[a-z]{1,10}>//g' |
grep -oP '(?<!\w)((c#)|(c)|(java)|(javascript)|(typescript)|(js)|(ts)|(python)|(linux)|(elixir)|(erlang)|(go)|(c\+\+)|(react)|(angular)|(svelte)|(\.net)|(embedded)|(rust)|(scala)|(clojure)|(kotlin)|(ruby)|(swift)|(golang))(?=[ ,./])' |
sort | uniq -c | sort -nr
    583 java
    558 python
    508 .net
    487 embedded
    434 c++
    411 c#
    339 c
    327 react
    311 linux
    238 javascript
    217 typescript
    176 js
    165 angular
    107 go
    104 kotlin
     64 ts
     40 swift
     34 rust
     34 golang
     29 scala
     13 ruby
      4 svelte
      4 erlang
      2 elixir
      1 clojure

Very interesting. I expected Java to be high, but I honestly thought C#/.NET would be higher. Same with the JS/TS + frameworks. Python is also highly sought after, which is expected.

Now, Go also happens to be a common English word, and given that many of these ads are written in English, the likelyhood of Go being overcounted is very high. I'm surprised to see it rank so low, regardless.

What I'm most interested in is the amount of listings that contain the word "embedded". As mentioned in a previous blog post, I've gotten quite fond of systems level programming. With the understanding that I'd need to learn some rudimentary electrical engineering, maybe I should take a shot at becoming an embedded developer. It sounds fun, not gonna lie.

OSSU 2024 In Review

2024-12-28T20:00:00Z

This year I started the OSSU Computer Science curriculum (with modifications). Here's how that has gone as of the end of 2024:

Nand2Tetris: ✅ Completed, 2024-04-20
Systematic Program Design: ✅ Completed, 2024-09-21
Discrete Mathematics by Epp, S. ⏩ In-progress, chapter 8/12
Introduction to Computer Systems ⏩ In-progress, lecture 15/27, lab 4/7

Nand2Tetris

This course taught me that I can learn anything I want. It also taught me a bunch of cool things about computer architecture.

Nand2Tetris is a course that takes you all the way from basic digital logic circuits to computer that can (int theory) run tetris. Through a series of projects you get to specify all the hardware components of a whole computer (they give you a clock, a screen, and a keyboard for free), make an assembler, a two-stage compiler for a simple programming language, and an OS written in that language.

The course gives each of its subjects a surface-level treatment, focusing instead on how each subject relates to the other, For an introductory computer architecture course, I think that is perfect. You really get an intuition for why things are the way they are, while at the same time giving you an opportunity to get a feel for a variety of subjects in Computer Science that you can then choose to make a deeper dive into.

It's also great for building intuition about how computers actually. Before this course, the low-level mechanics of how memory and CPU instructions work were pure magic, but afterwards I had all the tools I needed to reason about it. This was especially helpful for the first half of the Introduction to Computer Systems course (especially the machine programming parts), since most of it was just the specifics of how x86-64 implements concepts I already learned in N2T.

Systematic Program Design

This is a solid small-scale software design course. I mostly took this course to see what sort of programming practices they're teaching young programmers these days, and I'm happy to report that the state of things is pretty good at this level at least. I'm especially happy about the TDD-style approach to things, even though this course's variation of it is more of a top-down approach than what Kent Beck had in mind. I also think if you treat the design recipes as ways to reason about a problem, and the templates as drilling exercises to get you used to that kind of reasoning, you'll get a lot out of this course. You're not supposed be copy-pasting templates in your professional work, but doing it the first few times will help you establish those thought patterns.

Discrete Mathematics

I think I've learned how to enjoy math. I don't know if it's The Joy of Learning in general, or if there's something specific about math. I think part of it might be that I really enjoy exploring systems of logic, and what is mathematics if not that. So far in this book I've explored propositional logic, number theory, sequences and induction, set theory, and relations and functions. I will admit one thing, however: number theory is not really my jam. I've noticed that my progress slows down significantly the more number theory I'm doing. Everything else is super cool though.

Introduction to Computer Systems

I'm going to make a bold claim. Carnegie Mellon University consistently ranks among the best universities in the world for Computer Science, and this course is one of the major reasons why. It covers a lot of the same material as Nand2Tetris but in much greater detail, and in the context of real-world hardware and software. The best way I can describe this course is that it bridges the gap between hardware and operating system. Like Nand2Tetris, it is not a course that covers one singular subject, but rather a collection of subjects that all relate to and build on each other. So far I've learned about binary data representation (I finally understand how floats work), x86-64 machine code, pipelining and optimization, the memory hierarchy, and a bit of OS stuff. Now, this is a difficult course. You cannot simply read the book and watch the lectures, and then go on your merry day, you will not learn a thing from that. You have to do the practice problems from the book, you have to do the labs, and sometimes, it takes a few tries to fully get a concept (I had to do several passes on code optimization in order to fully get how to reason about data-dependencies and pipelined CPU-instructions), but once you get it, it is so rewarding. One thing to note is, you need the textbook, which is called Computer Systems: A Programmer's Perspective, you need the US-edition specifically, and there are no good versions online, in stores or on the seven seas. And the print version is $160. So keep that in mind.

Lessons Learned

The most important thing I learned this year was how to structure myself and my own learning, and to be consistent with it. It's something I always struggled with.

Another thing is the need to pace myself. It's commonly said on the OSSU discord that "speedrunning always takes longer". This is true in two ways:

Rushing things is a detriment to learning. When you feel like you're in a hurry, you tend to skip over things, not do problems, etc. and as a result you don't learn what's needed in order to proceed. The result is a need to go back and repeat things you were already supposed to have learned. Take your time.
Burnout. Something like OSSU is a multi-year project. It turns out, learning a bachelor's/master's degree worth of material is going to take about a bachelor's/master's degree amount of time. Pushing yourself and overworking yourself for that long is gonna bite you, it's gonna lead to burn you out, and it's gonna slow you down in the long run. I realized at some point, that I needed to learn how to force myself to relax. That means finding an activity wholly unrelated to studies or work. Play videogames, hang out with friends, drink a cup of tea while watching a show. Just make sure you relax.

What's Next?

I try not to plan things too far. Usually the final decision on "what course/book/thing comes next" is made the moment i finish my current thing. With that being said, there's at least a few topics I want to explore in the new year.

Algorithms

This is the natural next step after discrete mathematics. Part of why I started this whole thing was, that I wanted to become a better programmer, and the things I wanted to work on were the bare fundamentals. This is just that.

I'll be taking the theoretical approach for the simple reason that I'm a nerd for theory. That means studying algorithms not as a subject of programming, but as a subject of math. Looking forward to it!

Operating Systems

Clearly I've caught the systems programming bug. I just think it's neat. I've got no idea if I'll ever get to work in systems programming professionally, but at the very least I find it fun right now.

The popular self-study course on this topic is OSTEP, and that's most likely the course I'm going to follow. Free online textbooks are just too good to pass up on.

Code blocks

2024-12-28T19:00:00Z

In my quest to do as little web-development as possible when making this site, I decided to just fork this base blog repo, and make some minor changes to the CSS to fit my needs (such as setting this lovely gruvbox-dark color-scheme). As it turns out, this base blog comes with the syntax highlighting plugin configured, which uses PrismJS to do syntax-highlighting on code snippets. It even comes with a few preset CSS themes. Now, none of those themes were gruvbox-dark, but no problem, I just copied the solarized theme and changed the colors to (mostly) match my neovim color-scheme. I think it turned out quite nicely:

//comment
int main(int argc, char** argv) {
	printf("Hello, World!");
}

fn main() {
	println!("Hello, World");
}

public class Main {
	public static void main(String[] args) {
		System.out.println("Hello, World!");
	}
}

We're live

2024-12-15T21:35:00Z

Finally got around to registering a domain name and picking a static site generator to use for my personal site (11ty, if you're curious).

I figured it would be nice to have a place to write about various things I learn along the way, or silly adventures in technology would be nice, as well as maybe hosting an online CV of sorts.

Let's see where this goes :3

0x1eaf

Social Media Preview Images

2025 Computer Science Self-Study in Review

Discrete Mathematics

Introduction to Computer Systems

Stanford Online Algorithms Specialization

Operating Systems: Three Easy Pieces

So what did we learn

Looking ahead

The Case of the Missing Race Condition

Running and debugging xv6 for OSTEP in a Docker container

So how do I use this thing?

Building, running, and debugging xv6

What I learned from re-implementing Malloc

What's in an allocator

The malloc API

How is this thing scored

Implicit free-list - the textbook implementation

Second iteration: explicit free-list

But first, it's time to stop cheating

Third iteration: segregated free-list

A second look at realloc

So what did we learn

we do a little data wrangling

OSSU 2024 In Review

Nand2Tetris

Systematic Program Design

Discrete Mathematics

Introduction to Computer Systems

Lessons Learned

What's Next?

Algorithms

Operating Systems

Code blocks

We're live

A second look at `realloc`