mirror of
https://github.com/Noratrieb/blog.git
synced 2026-01-14 12:35:00 +01:00
161 lines
No EOL
20 KiB
XML
161 lines
No EOL
20 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on nilstriebs blog</title><link>/posts/</link><description>Recent content in Posts on nilstriebs blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Fri, 22 Jul 2022 00:00:00 +0000</lastBuildDate><atom:link href="/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Box Is a Unique Type</title><link>/posts/box-is-a-unique-type/</link><pubDate>Fri, 22 Jul 2022 00:00:00 +0000</pubDate><guid>/posts/box-is-a-unique-type/</guid><description>We have all used Box&lt;T&gt; before in our Rust code. It&rsquo;s a glorious type, with great ergonomics and flexibitility. We can use it to put our values on the heap, but it can do even more than that!
|
|
struct Fields { a: String, b: String, } let fields = Box::new(Fields { a: &#34;a&#34;.to_string(), b: &#34;b&#34;.to_string() }); let a = fields.a; let b = fields.b; This kind of partial deref move is just one of the spectacular magic tricks box has up its sleeve, and they exist for good reason: They are very useful.</description><content><p>We have all used <code>Box&lt;T&gt;</code> before in our Rust code. It&rsquo;s a glorious type, with great ergonomics
|
|
and flexibitility. We can use it to put our values on the heap, but it can do even more
|
|
than that!</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Fields</span> {
|
|
</span></span><span style="display:flex;"><span> a: String,
|
|
</span></span><span style="display:flex;"><span> b: String,
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> fields <span style="color:#f92672">=</span> Box::new(Fields {
|
|
</span></span><span style="display:flex;"><span> a: <span style="color:#e6db74">&#34;a&#34;</span>.to_string(),
|
|
</span></span><span style="display:flex;"><span> b: <span style="color:#e6db74">&#34;b&#34;</span>.to_string()
|
|
</span></span><span style="display:flex;"><span>});
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> a <span style="color:#f92672">=</span> fields.a;
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> b <span style="color:#f92672">=</span> fields.b;
|
|
</span></span></code></pre></div><p>This kind of partial deref move is just one of the spectacular magic tricks box has up its sleeve,
|
|
and they exist for good reason: They are very useful. Sadly we have not yet found a way to generalize all
|
|
of these to user types as well. Too bad!</p>
|
|
<p>Anyways, this post is about one particularly subtle magic aspect of box. For this, we need to dive
|
|
deep into unsafe code, so let&rsquo;s get our hazmat suits on and jump in!</p>
|
|
<h1 id="an-interesting-optimization">An interesting optimization</h1>
|
|
<p>We have this code here:</p>
|
|
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">takes_box_and_ptr_to_it</span>(<span style="color:#66d9ef">mut</span> b: Box<span style="color:#f92672">&lt;</span><span style="color:#66d9ef">u8</span><span style="color:#f92672">&gt;</span>, ptr: <span style="color:#f92672">*</span><span style="color:#66d9ef">const</span> <span style="color:#66d9ef">u8</span>) {
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> value <span style="color:#f92672">=</span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#f92672">*</span>ptr };
|
|
</span></span><span style="display:flex;"><span> <span style="color:#f92672">*</span>b <span style="color:#f92672">=</span> <span style="color:#ae81ff">5</span>;
|
|
</span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> value2 <span style="color:#f92672">=</span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#f92672">*</span>ptr };
|
|
</span></span><span style="display:flex;"><span> assert_ne!(value, value2);
|
|
</span></span><span style="display:flex;"><span>}
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> b <span style="color:#f92672">=</span> Box::new(<span style="color:#ae81ff">0</span>);
|
|
</span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> ptr: <span style="color:#f92672">*</span><span style="color:#66d9ef">const</span> <span style="color:#66d9ef">u8</span> <span style="color:#f92672">=</span> <span style="color:#f92672">&amp;*</span>b;
|
|
</span></span><span style="display:flex;"><span>
|
|
</span></span><span style="display:flex;"><span>takes_box_and_ptr_to_it(b, ptr);
|
|
</span></span></code></pre></div><p>There&rsquo;s a function, <code>takes_box_and_ptr_to_it</code>, that takes a box and a pointer as parameters. Then,
|
|
it reads a value from the pointer, writes to the box, and reads a value again. It then asserts that
|
|
the two values aren&rsquo;t equal. How can they not be equal? If our box and pointer point to the same
|
|
location in memory, writing to the box will cause the pointer to read the new value.</p>
|
|
<p>Now construct a box, get a pointer to it, and pass the two to the function. Run the program&hellip;</p>
|
|
<p>&hellip; and everything is fine. Let&rsquo;s run it in release mode. This should work as well, since the optimizer
|
|
isn&rsquo;t allowed to change observable behaviour, and an assert is very observable. Run the progrm&hellip;</p>
|
|
<pre tabindex="0"><code>thread &#39;main&#39; panicked at &#39;assertion failed: `(left != right)`
|
|
left: `0`,
|
|
right: `0`&#39;, src/main.rs:5:5
|
|
</code></pre><p>Hmm. That&rsquo;s not what I&rsquo;ve told would happen. Is the compiler broken? Is this a miscompilation?
|
|
I&rsquo;ve heard that those do sometimes happen, right?</p>
|
|
<p>Trusting our instincts that &ldquo;it&rsquo;s never a miscompilation until it is one&rdquo;, we assume that LLVM behaved
|
|
well here. But what allows it to make this optimization? Taking a look at the generated LLVM-IR (by using
|
|
<code>--emit llvm-ir -O</code>, the <code>-O</code> is important since rustc only emits these attributes with optimizations on)
|
|
reveals the solution: (severely shortened to only show the relevant parts)</p>
|
|
<pre tabindex="0"><code class="language-llvmir" data-lang="llvmir">define void @takes_box_and_ptr_to_it(i8* noalias %0, i8* %ptr) {
|
|
</code></pre><p>See the little attribute on the first parameter called <code>noalias</code>? That&rsquo;s what&rsquo;s doing the magic here.
|
|
<code>noalias</code> is an LLVM attribute on pointers that allows for various optimizations. If there are two pointers,
|
|
and at least one of them is <code>noalias</code>, there are some restrictions around the two. Approximately:</p>
|
|
<ul>
|
|
<li>If one of them writes, they must not point to the same value (alias each other)</li>
|
|
<li>If neither of them writes, they can alias just fine.
|
|
Therefore, we also apply <code>noalias</code> to <code>&amp;mut T</code> and <code>&amp;T</code> (if it doesn&rsquo;t contain interior mutability through
|
|
<code>UnsafeCell&lt;T&gt;</code>, since they uphold these rules.</li>
|
|
</ul>
|
|
<p>This might sound familiar to you if you&rsquo;re a viewer of <a href="https://twitter.com/jonhoo">Jon Gjengset</a>&rsquo;s content (which I can highly recommend). Jon has made an entire video about this before, since his crate <code>left-right</code>
|
|
was affected by this (<a href="https://youtu.be/EY7Wi9fV5bk)">https://youtu.be/EY7Wi9fV5bk)</a>.</p>
|
|
<p>If you&rsquo;re looking for <em>any</em> hint that using box emits <code>noalias</code>, you have to look no further than the documentation
|
|
for <a href="https://doc.rust-lang.org/nightly/std/boxed/index.html#considerations-for-unsafe-code"><code>std::boxed</code></a>. Well, the nightly or beta docs, because I only added this section very recently. For years, this behaviour was not really documented, and you had to
|
|
belong to the arcane circles of the select few who were aware of it. So lots of code was written thinking that box was &ldquo;just an
|
|
RAII pointer&rdquo; (a pointer that allocates the value in the constructor, and deallocates it in the destructor on drop) for all
|
|
pointers are concerned.</p>
|
|
<h1 id="stacked-borrows-and-miri">Stacked Borrows and Miri</h1>
|
|
<p>TODO: introduce UB by explaining how it allows optimizations like the one above, don&rsquo;t talk in standardese</p>
|
|
<p><a href="https://github.com/rust-lang/miri">Miri</a> is an interpreter for Rust code with the goal of finding undefined behaviour.
|
|
Undefined behaviour, UB for short, is behaviour of a program upon which no restrictions are imposed. If UB is executed,
|
|
<em>anything</em> can happen, including segmentation faults, silent memory corruption, leakage of private keys or exactly
|
|
what you intended to happen. Examples of UB include use-after-free, out of bounds reads or data races.</p>
|
|
<p>I cannot recommend Miri highly enough for all unsafe code you&rsquo;re writing (sadly support for some IO functions
|
|
and FFI is still lacking, and it&rsquo;s still very slow).</p>
|
|
<p>So, let&rsquo;s see whether our code contains UB. It has to, since otherwise the optimizer wouldn&rsquo;t be allowed to change
|
|
observable behaviour (since the assert doesn&rsquo;t fail in debug mode). <code>$ cargo miri run</code>&hellip;</p>
|
|
<pre tabindex="0"><code class="language-rust,ignore" data-lang="rust,ignore">error: Undefined Behavior: attempting a read access using &lt;3314&gt; at alloc1722[0x0], but that tag does not exist in the borrow stack for this location
|
|
--&gt; src/main.rs:2:26
|
|
|
|
|
2 | let value = unsafe { *ptr };
|
|
| ^^^^
|
|
| |
|
|
| attempting a read access using &lt;3314&gt; at alloc1722[0x0], but that tag does not exist in the borrow stack for this location
|
|
| this error occurs as part of an access at alloc1722[0x0..0x1]
|
|
|
|
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
|
|
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
|
|
help: &lt;3314&gt; was created by a retag at offsets [0x0..0x1]
|
|
--&gt; src/main.rs:10:26
|
|
|
|
|
10 | let ptr: *const u8 = &amp;*b;
|
|
| ^^^
|
|
help: &lt;3314&gt; was later invalidated at offsets [0x0..0x1]
|
|
--&gt; src/main.rs:12:29
|
|
|
|
|
12 | takes_box_and_ptr_to_it(b, ptr);
|
|
| ^
|
|
= note: backtrace:
|
|
= note: inside `takes_box_and_ptr_to_it` at src/main.rs:2:26
|
|
note: inside `main` at src/main.rs:12:5
|
|
--&gt; src/main.rs:12:5
|
|
|
|
|
12 | takes_box_and_ptr_to_it(b, ptr);
|
|
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
</code></pre><p>This behaviour does indeed not look very defined at all. But what went wrong? There&rsquo;s a lot of information here.</p>
|
|
<p>First of all, it says that we attempted a read access, and that this access failed because the tag does not exist in the
|
|
borrow stack of the byte that was accessed. This is something about stacked borrows, the experimental memory model for Rust
|
|
that is implemented in Miri. For an excellent introduction, see this part of the great book <a href="https://rust-unofficial.github.io/too-many-lists/fifth-stacked-borrows.html">Learning Rust With Entirely Too Many Linked Lists</a>.</p>
|
|
<p>In short: each pointer has a unique tag attached to it. Each byte in memory has its own &lsquo;borrow stack&rsquo; of these tags,
|
|
and only the pointers that have their tag in the stack are allowed to access it. Tags can be pushed and popped from the stack through various operations, for example borrowing.</p>
|
|
<p>In the code example above, we get a nice little hint where the tag was created. When we created a reference (that was then
|
|
coerced into a raw pointer) from our box, it got a new tag called <code>&lt;3314&gt;</code>. Then, when we moved the box into the function,
|
|
something happened: The tag was popped off the borrow stack and therefore invalidated. That&rsquo;s because box invalidates all tags
|
|
when it&rsquo;s moved. The tag was popped off the borrow stack and we tried to read with it anyways - undefined behaviour happened!</p>
|
|
<p>And that&rsquo;s how our code wasn&rsquo;t a miscompilation, but undefined behaviour. Quite surprising, isn&rsquo;t it?</p>
|
|
<h1 id="noalias-nothanks">noalias, nothanks</h1>
|
|
<p>Many people, myself included, don&rsquo;t think that this is a good thing.</p>
|
|
<p>First of all, it introduces more UB that could have been defined behaviour instead. This is true for almost all UB, but usually,
|
|
there is something gained from the UB that justifies it. We will look at this later. But allowing such behaviour is fairly easy:
|
|
If box didn&rsquo;t invalidate pointers on move and instead behaved like a normal raw pointer, the code above would be sound.</p>
|
|
<p>But more importantly, this is not behaviour generally expected by users. While it can be argued that box is like a <code>T</code>, but on
|
|
the heap, and therefore moving it should invalidate pointers, since moving <code>T</code> definitely has to invalidate pointers to it,
|
|
this comparison doesn&rsquo;t make sense to me. While <code>Box&lt;T&gt;</code> usually behaves like a <code>T</code>, it&rsquo;s just a pointer. Writers of unsafe
|
|
code <em>know</em> that box is just a pointer, and will abuse that knowledge, accidentally causing UB with it. While this can be
|
|
mitigated with better docs and teaching, like how no one questions the uniqueness of <code>&amp;mut T</code> (maybe that&rsquo;s also because that
|
|
one makes intuitive sense, &ldquo;shared xor mutable&rdquo; is a simple concept), I think it will always be a problem,
|
|
because in my opinion, box being unique and invalidating pointers on move is simply not intiutive.</p>
|
|
<p>When a box is moved, the pointer bytes change their location in memory. But the bytes the box points to stay the same. They don&rsquo;t
|
|
move in memory. This is the fundamental missing intuition about the box behaviour.</p>
|
|
<p>There are also other reasons why the box behaviour is not desirable. Even people who know about the behaviour of box will want
|
|
to write code that goes directly against this behaviour at some point. But usually, fixing it is pretty simple: Storing a raw
|
|
pointer (or <code>NonNull&lt;T&gt;</code>) instead of a box, and using the constructor and drop to allocate and deallocate the backing box.
|
|
This is fairly inconvenient, but totally acceptable. There are bigger problems though. There are crates like <code>owning_ref</code>
|
|
that want to expose a generic interface over any type. Users like to choose box, and sometimes <em>have</em> to chose box because of
|
|
other box-exclusive features it offers. Even worse is <code>string_cache</code>, which is extremely hard to fix.</p>
|
|
<p>Then last but not least, there&rsquo;s the opinionated fact that <code>Box&lt;T&gt;</code> shall be implementable entirely in user code. While we are
|
|
many missing language features away from this being the case, the <code>noalias</code> case is also magic descended upon box itself, with no
|
|
user code ever having access to it.</p>
|
|
<h1 id="noalias-noslow">noalias, noslow</h1>
|
|
<p>There are also several arguments in favour of box being unique and special cased here. To negate the last argument above, it can
|
|
be said that <code>Box&lt;T&gt;</code> <em>is</em> a very special type. It&rsquo;s just like a <code>T</code>, but on the heap. Using this mental model, it&rsquo;s very easy to
|
|
justify all the box magic and its unique behaviour.</p>
|
|
<p>This mental model is one that many people have, but what does this bring us? This is just one mental model of box, and
|
|
there are other mental models of it (like &ldquo;a reference that manages its lifetime itself&rdquo; or &ldquo;a safe RAII pointer&rdquo;).</p>
|
|
<p>There is one clear potential benefit from this box behaviour. ✨Optimizations✨. <code>noalias</code> doesn&rsquo;t exist for fun, it&rsquo;s something
|
|
that can bring clear performance wins (for <code>noalias</code> on <code>&amp;mut T</code>, those were measureable). So the only question remains:
|
|
How much performance does <code>noalias</code> on <code>Box&lt;T&gt;</code> give us now, and how much potential performance improvements could we get in the
|
|
future? For the latter, there is no simple answer. For the former, there is. <code>rustc</code> has <a href="https://github.com/rust-lang/rust/pull/99527"><em>no</em> performance improvements</a> from being compiled with <code>noalias</code> on <code>Box&lt;T&gt;</code>.</p>
|
|
<p>I have not yet benchmarked ecosystem crates without box noalias and don&rsquo;t have the capacity to do so right now, so I would be very
|
|
grateful if anyone wanted to pick that up and report the results.</p>
|
|
<h1 id="a-way-forward">a way forward</h1>
|
|
<p>Based on all of this, I do have a solution that, in opinion, will fix all of this, even potential performance regressions with
|
|
box. First of all, I think that even if there are some performance regressions in ecosystem crates, the overall tradeoff goes
|
|
against the current box behaviour. Unsafe code wants to use box, and it is reasonable to do so. Therefore I propose to completely
|
|
remove all uniqueness from <code>Box&lt;T&gt;</code>, and treat it just like a <code>*const T</code> for the purposes of aliasing. This will make it more
|
|
predictable for unsafe code, and comes at none or only a minor performance cost.</p>
|
|
<p>But this performance cost may be real, and especially the future optimization value can&rsquo;t be certain. I do think that there
|
|
should be a way to get the uniqueness guarantees in some other way than through box. One possibility would be to use a <code>&amp;'static mut T</code> that is unleaked for drop, but the semantics of this are still <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/316">unclear</a>. If that is not possible, maybe exposing <code>std::ptr::Unique</code> (with it getting boxes aliasing semantics) could be desirable. For this, all existing usages of <code>Unique</code> inside the standard library would have to be removed though.</p>
|
|
<p>I guess what I am wishing for are some good and flexible raw pointer types. That&rsquo;s still in the stars&hellip;</p>
|
|
<p>For more information about this topic, see <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/326">https://github.com/rust-lang/unsafe-code-guidelines/issues/326</a></p></content></item></channel></rss> |