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.
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.
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.
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 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.
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.
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.
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.
I have had some thoughts on what privacy is used for in programming
languages, and how it differs from the notion of dependence between
modules (or at least compilation units) in a language like Rust.
And I thought I should share.