The {pnk}f(eli)x Blog

The informal ramblings of an ex-pat PL enthusiast

Road to TurboWish Part 3: Design

This is part three in a series about the TurboWish performance analysis tool suite. In part one I described why our team selected this as a focus, and the goals for the tools. In part two I presented four narratives, each representing different idealized future customer experiences using the tools.

Now I want to show you the design document I developed, which digs more into how I thinkI cannot emphasize enough that nothing here is set in stone. These are ideas I am circulating with you precisely so that you can tell me what needs to change. the system should be architected.

Road to TurboWish; Part 2: Stories

It’s story-time!

As I walk, I think about a new way to walk

In my previous post, I described the observations that led us to select performance tooling as a focus, as well as the goals document I wrote to guide the next steps of the project. Now I want to show you the User Stories I wrote, to show what I think our customers want (and can reasonably expect) out of performance tools.

Road to TurboWish; Part 1: Goals

This is a post about some recent history. I want to tell the world about a project I am leading at Amazon Web Services, called “TurboWish.”

TurboWish, in a nutshell, is our umbrella term for a planned suite of tools for understanding your Rust program’s dynamic behavior. We want the tools to especially focus on providing insights into the performance characteristics of your program.

How to Dismantle an Atomic Bomb

The problem

Driving deallocation of state via ref-counting under our current atomic API means that you cannot avoid having a &AtomicUsize variable at the same time that you are deallocating the block of memory that contains the referenced atomic usize state.

The proposal

The idea is simple.

Experienced Rustaceans know that in the general case, &T doesn’t actually mean immutable; it merely signals that unsynchronized mutation through aliases is disallowed. Interior mutability is still an option, via Cell or AtomicUsize.

All such sources of interior mutability are tracked in the type system. Namely, they all have an UnsafeCell<U> somewhere in the structure layout that tells the compiler that such mutation is permitted on the U inside the unsafe cell. Thus the compiler knows it cannot make optimizations that rely on that U remaining invariant.

So, here’s the suggested change: if code needs to allow for concurrent actors (or even aliasing accesses on the current thread) to mutate some state, that same code must allow that those accesses might deallocate that state.

Mentoring Rust Diagnostics Issue 81658

This was originally a github comment that, due to my writing style (and desire to teach), spun a bit out of control (or at least, didn’t match the overall style we try to follow for comments on rust-lang/rust repository).

So now, this is a blog post instead, where I get to do fun things like have better control over formatting and whatnot. (Based on what feedback I get on the post, maybe I will next work to promote it to a chapter in the rustc dev guide.)

Issue #81658, “Invalid `field is never read: ` lint warning”, is a bug filed against rustc.

These are mentorship instructions for how to go about fixing the bug. They are also an overview of some steps I use to get started looking at a bug like this.

Rust Bug Minimization Patterns

Update 19 November 2019: fixed miscellaneous typos and a bug in the invariance example pointed out by readers both privately and on reddit thread. I also added a section near the beginning to draw attention to techniques that are somewhat Rust-specific and may not be broadly known.

Hey there again!

I have been pretty busy with Rust compiler tasks, so no there has not been a blog post for a few months. But now, here we are!

While I was working some particularly nasty bugs recently, I put a lot of effort into bug minimization: the process of taking a large test case and finding ways to remove code from the test while preserving the test’s ability to expose the same bug.

As I worked, I realized that I was following a somewhat mechanical process. I was using regular patterns for code transformation. At some point, I said “you know, I’m not sure if everyone is aware of these patterns. I only remember some of them while I am in the middle of a bug minimization session.”

Since the Rust compiler team always wants to help newcomers learn ways they can contribute to the project, I realized this could be the ideal subject for a blog post.

And, to try to keep things concrete, I’m going to try to drive the presentation by showing an actual bug being minimized. (Or rather, I’m going to recreate the minimization that I already did. So if it seems like I am rather conveniently picking transformations that always seem to work: You’re right! I’m cheating and not telling you about all the false paths I went down during my first minimization odyssey on this bug.

Breaking News: Non-Lexical Lifetimes Arrives for Everyone

Update 1 July 2019: fixed bugs in EscapingWriter and as_reader examples.

Update 8 July 2019: fixed a new bug in as_reader example.

Hey there everyone!

It has been literally years since I last posted to this blog. I have been doing a bunch of Rust compiler work. One big feature has been deployed: Non-Lexical Lifetimes (hereafter denoted “NLL”).

The motivation for this blog post: The next version of Rust, 1.36, is going to have NLL turned on for the 2015 edition. Going forward, all editions of Rust will now use NLL. That is a big change. It is mostly a change that empowers developers; but it also is a change that will cause some existing code to break.

This post is going to talk a little bit about what NLL is and why you as a Rust developer should be excited about it as a feature (because it enables programmers to express themselves more directly).

However, even though the main feature of NLL is to increase the set of programs that Rust accepts, the vast majority of this post will focus on cases where the switch to NLL has caused the compiler to start rejectingRejecting unsound code is also a Rust feature that I value highly; but it often fails to excite developers, especially when it causes their legacy code to stop compiling. code that it used to accept erroneously.

GC and Rust Part 2: The Roots of the Problem

This is the second in a series of posts will discuss why garbage collection is hard, especially for Rust, and brainstorm about solutions to the problems we face.

The previous post wrote down some criteria for integration. Now I want to delve into why satisfying those criteria is hard, at least in Rust as it stands today.