Virtual memory mappings

Key Takeaways

So if you spin it up, that's the same content. It's the same page. Why would I ever want to load 10 copies of the same code that doesn't change? So the kernel will just load the code in memory, right? And then we'll point the first process to that. So the virtual memory of the first process will map to the same physical memory. The virtual memory to the second process for the code space of Node.js will map to the same physical memory. Although it could be the same virtual address. Could be different. Doesn't matter. But the idea of sharing memory is is beautiful, right? And of course security. Now that we have this layer in the middle, we can essentially essentially know that oh, you're trying to access something you already don't belong to. Tons tons and tons of features. Because now we have this uh translation that is required, uh someone needs to do the translation, right? Between virtual memory to um to physical memory. And who's doing that? Uh believe it or not, it's not the kernel. It's actually the CPU. See? There's a piece in the CPU, it's called the memory management unit, MMU. The CPU has a register called CR3. And that register points to a physical address that has the necessary metadata for this translation that we're going to talk about how this translation is happening between virtual memory and a and physical memory. And then the CPU does this walk to actually does the translation. So the MMU, every time we're trying to access something, the MMU kicks in and says like, all right, this is a virtual address, let me convert to a physical address. Up, let's let's walk the memory. So now we're walking physical memory to do that translation. We get back the physical memory, and then we we actually do the read.