Posts

I was watching Tsoding, where he questioned what a memory leak really means. He argues the definition is unclear for a few reasons: “Not freed before exiting” doesn’t help much because it is usually a good practice to pre-allocate a fixed size of memory, use it for the entirety of the program, and exiting doesn’t cause any issue. So we don’t really call this a leak. “Unreachable memory” has limits too. This definition sounds better, but it breaks down in practice. In some languages, you can manipulate pointers directly, which can trick a garbage collector into thinking memory is unreachable when it’s still in use. But even in languages like JavaScript where you don’t have access to pointers, you can “leak” memory by forgetting to clean up callbacks that hold references to objects. Those objects should be unreachable, but they’re not so memory keeps growing. You have a garbage collector and still leak memory. This is why Tsoding says there’s no clear definition of a memory leak. Tsoding suggests that a memory leak is more about what the programmer meant to do, not a strict rule. He also makes a deeper point that memory allocation itself is an artificial idea built on top of a fundamental computational model. So “leaks” are really just problems we created for ourselves. ...

Disclaimer: I’m not a trained psychologist, recruiter, or statistician. This article reflects my reasoning drawing mostly from Daniel Kahneman’s “Thinking, Fast and Slow” and personal experience. Most companies are terrible at hiring. Despite decades of research on human judgment and decision-making, most organizations continue to rely on processes that are barely better than random chance at predicting job performance. I’ve experienced this firsthand through two contrasting but equally flawed approaches at well-known tech companies. ...

In previous posts, we discovered how being memory-aware improves performance. The array-based BST was ~53% faster than its pointer-based counterpart, and we saw how garbage collection algorithms can spend 85% of their time stalled on memory accesses. But, there’s a fundamental layer we need to explore the virtual memory. Every memory access in a program goes through virtual memory translation. This blog post will try to explain: Why this layer exists? How it works? What is virtual memory? Processes in a system share the CPU and main memory with other processes. With sharing comes challenges. As demand for the CPU increases, processes slow down but, if too many processes need too much memory, then some of them will simply not be able to run. Memory is also vulnerable to corruption if some process writes to the memory used by another process that process might fail in some unpredictable fashion totally unrelated to the program logic. ...

For the sake of the article length, I won’t walk through running every command here. Instead, I’ve documented everything to make it seamless for you to reproduce these results yourself. I encourage you to run the profiling tools and discover the patterns firsthand. All code, scripts, and detailed instructions are available here Recap In the first blog post, we explored the effects of thoughtful memory layout. The array-based BST was 53% faster than the pointer-based version despite using more memory, because sequential access leverages CPU cache lines and having predictable access patterns optimize hardware prefetchers. In the previous blog post, we learned what garbage collection is and discovered that Go’s current GC suffers from the exact same problem: it spends 85% of its time chasing scattered pointers through memory, with over 35% of CPU cycles stalled on memory accesses - confirming our findings from the first post about spatial locality. Now, we’re going to explore how to identify when GC is bottlenecking your algorithms using real profiling tools like pprof and Instruments, and demonstrate how Green Tea’s span-based scanning approach could solve these memory access problems. Reading GC Traces We have a graph implementation that creates 2M random nodes and performs BFS by visiting all nodes. Running make run EXEC=graph sets GODEBUG=gctrace=1, which hints to any running Go application to start garbage collection tracing. ...

In the previous blog post, we learned the importance of memory latency and how to reduce its impact. Here we’re going to apply some of our learning and analyze parallel memory aware experimental Go’s garbage collector - green tea What is garbage-collector? Garbage collector’s main idea is to free programmer from manually allocating and freeing objects. Currently Go programming language uses concurrent tri-color mark-and-sweep collector (animation), which we’re going to explore and compare against experimental Green Tea garbage collector. ...

Memory latency is one of the factors impacting application performance. Join me on a quest to understand memory latency, how to measure it, and knowing when it can be improved. For this type of posts people usually use C/C++ but I’m going to stick to Go and occasionally bring in Rust for comparison since I’m mostly using these two languages and I want to show you the tools available to you. ...