Rust의 vtable 시각화: dyn Trait의 메모리 동작 원리

Visualizing Rust's Vtables: How dyn Trait Works In Memory I&rsquo;m venturing into Rust and it&rsquo;s both satisfying and mind-boggling at the same time. So far I&rsquo;ve been learning from the book and Mara Bos&rsquo; book , but I got the itch to do some dissecting myself. My initial goal of these experiments was to compare Rust&rsquo;s approach to polymorphism with C++&rsquo;s. Ultimately, however, as I&rsquo;ve come to realize, it&rsquo;s a bit of a trap when trying to understand a new language through another one to try to draw 1:1 parallels. It might seem like it helps, but at the end of the day, we can&rsquo;t treat Rust as C++ with different syntax. If that were the case, there&rsquo;d be nothing revolutionary about it. That said, I believe there is merit in poking around and coming to understand the why . So, if you&rsquo;re like me and need to know what exactly is happening in memory, in order to feel like you truly understand the concepts, hopefully you&rsquo;ll find this post useful :) By the way, the thumbnail image is a photo of the rust fungus, to which we owe Rust&rsquo;s name. Credit: gailhampshire from Cradley, Malvern, U.K , CC BY 2.0 , via Wikimedia Commons. You can find all the code and experiments on GitHub . Introduction: The Crux of the Matter What we&rsquo;re trying to achieve is quite simple. Let&rsquo;s say we have a bunch of shapes: circles, squares, triangles, and we want to call draw() on each one. C++ Approach #1: Virtual Functions The first way to do this that comes to mind in C++ is through virtual functions, which makes use of runtime polymorphism. The vtable pointer lives inside the object, virtual dispatch happens automatically. std :: vector < Shape *> shapes = { new Circle (), new Square () }; for ( auto * s : shapes ) s -> draw (); Rust&rsquo;s equivalent would be dyn Trait , which is what we ultimately want to understand. But first, let&rsquo;s take a look at another way we could solve this in C++. C++ Approach #2: CRTP One could also go the CRTP (Curiously Recurring Template Pattern) route, which is essentially compile time polymorphism. If you&rsquo;re interested, this awesome talk by Klaus Iglberger was my first introduction to the topic, and the one I keep coming back to for reference. template < typename Derived > struct Shape { void draw () { static_cast < Derived *> ( this ) -> draw (); } }; Essentially, there are no vtables and it&rsquo;s resolved at compile time, sacrificing readability (it really is a mouthful). Rust offers a much more straightforward and simple equivalent to CRTP, namely monomorphization. This is the approach we&rsquo;ll dig into first to start constructing our mental model of what Rust has to offer. Static Dispatch Static dispatch, also known as generics, achieves a similar result to CRTP: the compiler generates a separate copy of the function for each type it&rsquo;s called with. There is zero runtime cost, but the types must be known at compile time. trait Draw { fn draw ( & self ) -> & str ; } struct Circle ; struct Square ; impl Draw for Circle { fn draw ( & self ) -> & str { &#34;Drawing a circle&#34; } } impl Draw for Square { fn draw ( & self ) -> & str { &#34;Drawing a square&#34; } } fn draw_shape < T : Draw > ( shape : T ) { println! ( &#34; {} &#34; , shape . draw ()); } fn main () { let circle = Circle ; let square = Square ; draw_shape ( circle ); draw_shape ( square ); } Under the hood, the compiler generates two separate functions: draw_shape::<Circle> and draw_shape::<Square> . How does this compare to C++&rsquo;s templates? The difference here is the philosophy. C++ makes the constraints implicit, a template accepts any type T that happens to have a .draw() method. While, in Rust, you are typing out the contract explicitly: you &ldquo;implement the Draw trait for Square.&rdquo; My question is, when is this not enough? Before tackling this question, let&rsquo;s indulge a bit in a side quest. Side Quest: Rust&rsquo;s Zero-Sized Types I tried to look at the size of Circle and Square because I wanted to make the comparison to wide pointers, which we&rsquo;ll see in a bit, but it led me to discover something unexpected. In C++, the standard mandates that every object has a size of at least 1 byte, even if empty. This is so that two distinct objects always have distinct address, meaning &obj1 must be different from &obj2 . This is one of those things that is ingrained in my mind as a fact of nature, so seeing that rust returns 0 totally surprised me. These are the little moments that bring me so much joy as I&rsquo;m exploring Rust because it deconstructs my mental model and helps me appreciate the different philosophy. println! ( &#34; {} &#34; , std :: mem :: size_of :: < Circle > ()); // 0 WHAT??? println! ( &#34; {} &#34; , std :: mem :: size_of :: < Square > ()); // 0 This is how I discovered that Rust handles the unique address guarantee differently. Zero-sized types (ZST) are structs that don&rsquo;t contain any fields, therefore there&rsquo;s no need to allocate any memory. Rust tracks identity through ownership, not addresses. Every value has exactly one owner at a time, this is enforced at compile time by our friend, the borrow-checker. In C++, we might do this to check if two pointers refer to the same object: if ( & a == & b ) { // same object } In Rust, that question is answered by the borrow-checker at compile time: // the borrow checker already knows these are different bindings // you don't need to compare addresses to tell them apart let a = Circle ; let b = Circle ; The compiler tracks a and b as distinct names with distinct owners. After learning about this, my question was, what happens then if we take the address of a zst? Let&rsquo;s try it. let a = Circle ; let b = Circle ; println! ( &#34; {:p} &#34; , & a as * const Circle ); println! ( &#34; {:p} &#34; , & b as * const Circle ); The output: 0x7ffdda99aece 0x7ffdda99aecf Strange&mldr; so they are getting distinct stack addresses 1 byte apart ( ce and cf in hex). It might look like the compiler allocated a byte for each, just as C++ would, but this is simply a debug-mode behavior. The compiler assigns local ZST variables a dummy stack slot purely so debuggers can track and inspect them by reference. If we try this in release mode, however, we get different behavior: cargo run --release --bin 01_static_dispatch The addresses do indeed collapse for me: 0x7ffdf74afa6f 0x7ffdf74afa6f My take away from this is that the compiler makes no guarantees about ZST addresses, and identity is tracked by the borrow checker through ownership, not memory addresses. Dynamic Dispatch To continue on our main quest, let&rsquo;s see what dynamic dispatch would look like for our previous example: fn draw_shape ( shape : & dyn Draw ) { println! ( &#34; {} &#34; , shape . draw ()); } fn main () { let circle = Circle ; let square = Square ; draw_shape ( & circle ); draw_shape ( & square ); } It looks almost identical to the static dispatch version, the only difference is &dyn Draw instead of <T: Draw> . But something fundamentally different is happening underneath. Let&rsquo;s see what happens to the size: println! ( &#34;&Circle size: {} &#34; , std :: mem :: size_of :: <& Circle > ()); // 8 println! ( &#34;&dyn Draw size: {} &#34; , std :: mem :: size_of :: <& dyn Draw > ()); // 16 &dyn Draw is twice the size of a regular pointer. This is called a wide pointer : it&rsquo;s actually two pointers, one points to the data, the other to a vtable. That vtable is what tells Rust which draw() to call at runtime. We can inspect what those pointers look like: fn inspect ( shape : & dyn Draw ) { let ( data_ptr , vtable_ptr ) = unsafe { std :: mem :: transmute :: <& dyn Draw , ( usize , usize ) > ( shape ) }; println! ( &#34;data ptr: {:#x} &#34; , data_ptr ); println! ( &#34;vtable ptr: {:#x} &#34; , vtable_ptr ); } std::mem::transmute does a bit-for-bit copy from the source type ( &dyn Draw ) to the destination type ( (usize, us