The story of a V8 performance cliff in React
Efficient Go APIs with the mid-stack inliner
> A common task in Go API design is returning a byte slice. In this post I will explore some old techniques and a new one.
Trash talk: the Orinoco garbage collector
> Over the past years the V8 garbage collector (GC) has changed a lot. The Orinoco project has taken a sequential, stop-the-world garbage collector and transformed it into a mostly parallel and concurrent collector with incremental fallback.
Trashing the Flow of Data
> As has been shown many times before, often bugs that don’t seem exploitable at first can be turned into an arbitrary read/write. In this case in particular, triggering the garbage collector while our fake pointer was on the stack gave us a very strong exploitation primitive. The V8 team fixed the bug very quickly as usual. But more importantly, they’re planning to refactor the InferReceiverMaps function to prevent similar bugs in the future. When I noticed this function in the past, I was convinced that one of the callers will get it wrong and audited all the call sites. Back then I couldn’t find a vulnerability but a few months later I stumbled over this newly introduced code that didn’t add the right runtime checks. In hindsight, it would have been worthwhile to point out this dodgy API to the team even without vulnerabilities to show for.
A new runtime for Nim
> In this blog post I explore how the full Nim language can be used without a tracing garbage collector. Since strings and sequences in Nim can also be implemented with destructors the puzzle to solve is what to do with Nim’s ref pointers and new keyword.
> Type-specific allocation turns every “use after free” bug into a logical bug but no memory corruption can happen. So ... we have already accomplished “memory safety without a GC”. It didn’t require a borrow checker nor an advanced type system. It is interesting to compare this to an example that uses array indexing instead of pointers:
Exploring how and why interior pointers in Go keep entire objects alive
> Today, with indivisible compound objects, Go can keep a simple map from memory addresses to the block of memory that they keep alive and the garbage collector doesn’t have to care about the type of a pointer, just its address, because the address alone is what determines how much memory is kept alive. In a world where compound objects are divisible, we must somehow arrange for &b.smallThing and &b to be treated differently by the garbage collector, either by giving the garbage collector access to type information or by having them point to different addresses.
JVM Anatomy Quark #23: Compressed References
> But does that mean the size of Java reference is the same as the machine pointer width? Not necessarily. Java objects are usually quite reference-heavy, and there is pressure for runtimes to employ the optimizations that make the references smaller. The most ubiquitous trick is to compress the references: make their representation smaller than the machine pointer width.
PyPy for low-latency systems
> Recently I have merged the gc-disable branch, introducing a couple of features which are useful when you need to respond to certain events with the lowest possible latency.
Common Mistakes about Generational Garbage Collection
> To summarize: please choose your words carefully. “Young objects are more likely to die” is an accurate motivation, “Most objects die young” is not. This goes doubly if you do understand the subtlety: do not assume the people you are talking with have an accurate model of how garbage works.
The benefits and costs of writing a POSIX kernel in a high-level language
> The paper contributes Biscuit, a kernel written in Go that implements enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file system, poll, etc.) to execute significant applications. Biscuit makes lib- eral use of Go’s HLL features (closures, channels, maps, interfaces, garbage collected heap allocation), which sub- jectively made programming easier. The most challenging puzzle was handling the possibility of running out of ker- nel heap memory; Biscuit benefited from the analyzability of Go source to address this challenge.
Good enough to run nginx.
Java's new Z Garbage Collector (ZGC) is very exciting
> Java 11 has recently been feature frozen and contains some really great features, one in particular we’d like to highlight. The release contains a brand new Garbage Collector, ZGC, which is being developed by Oracle that promises very low pause times on multi-terabyte heaps. In this article we’ll cover the motivation for a new GC, a technical overview and some of the really exciting possibilities ZGC opens up.
> A whirlwind tour of the Go memory allocator and garbage collector, with tools and tips on how to optimize.
Rather deep for a whirlwind tour.
Getting to Go
> This is the transcript from the keynote I gave at the International Symposium on Memory Management (ISMM) on June 18, 2018. For the past 25 years ISMM has been the premier venue for publishing memory management and garbage collection papers and it was an honor to have been invited to give the keynote.
Three kinds of memory leaks
> But when we say “memory leak”, what do we actually mean? In my experience, apparent memory leaks divide into three broad categories, each with somewhat different behavior, and requiring distinct tools and approaches to debug. This post aims to describe these classes, and provide tools and techniques for figuring out both which class you’re dealing with, and how to find the leak.
The Infamous GNOME Shell Memory Leak
> Explain in greater details what is the issue (or at least, what we think it is), the journey to find it, and how it was fixed.
Garbage collection works best when you remember to do the collecting.
Rust Lifetimes for the Uninitialised
> Lifetimes are a interesting subject: a lot of people seem to gain a day-to-day familiarity with them, without fully understanding what they are. Maybe, they are truly Rust’s Monads. Let’s talk about what they are, where you encounter them and then how to get competent with them.
Reducing Memory Usage in Ruby
> I’ve been working on building a compacting garbage collector in Ruby for a while now, and one of the biggest hurdles for implementing a compacting GC is updating references. For example, if Object A points to Object B, but the compacting GC moves Object B, how do we make sure that Object A points to the new location?
Copy-on-write friendly Python garbage collection
> Enabling GC could alleviate this problem and slow down the memory growth, but undesired Copy-on-write (COW) would still increase the overall memory footprint. So we decided to see if we could make Python GC work without COW, and hence, the memory overhead.
Malloc Can Double Multi-threaded Ruby Program Memory Usage
> The problem manifests itself as a slow, creeping memory growth in Ruby processes. It is often mistaken for a memory leak. However, unlike a memory leak, memory growth due to fragmentation is logarithmic, while memory leaks are linear.
This starts off with a simpe problem and fix, but lots of info about what’s happening.
Go, don't collect my garbage
> I started playing with the GOGC variable. First I set it to 2,400, which made sense since we have 24 cores, perhaps collecting garbage 24 times less frequently will do the trick: ECDSA-P256 Sign,671538.90, op/s, oh my that is getting better.