操作系统内存管理 - malloc() 调用

发布于 09-30 05:57 字数 379 浏览 4 评论 0原文

我正在研究操作系统内存管理,我希望验证我是否直接掌握了分配\虚拟内存\分页的基本机制。

假设一个进程调用 malloc(),幕后会发生什么? 我的回答:运行时库在其虚拟内存地址空间中找到适当大小的内存块。 (这是处理碎片的分配算法(例如first-fitbest-fit)发挥作用的地方)

现在假设进程访问该内存,这是如何完成的? 我的回答:从进程的角度来看,内存地址实际上是虚拟的。操作系统检查该地址当前是否映射到物理内存地址,如果是则执行访问。如果未映射,则会引发页面错误。

我明白了吗?即编译器\运行时库负责分配虚拟内存块,操作系统负责进程的虚拟地址和物理地址之间的映射(以及所需的分页算法)?

谢谢!

I'm studying up on OS memory management, and I wish to verify that I got the basic mechanism of allocation \ virtual memory \ paging straight.

Let's say a process calls malloc(), what happens behind the scenes?
my answer: The runtime library finds an appropriately sized block of memory in its virtual memory address space.
(This is where allocation algorithms such as first-fit, best-fit that deal with fragmentation come into play)

Now let's say the process accesses that memory, how is that done?
my answer: The memory address, as seen by the process, is in fact virtual. The OS checks if that address is currently mapped to a physical memory address and if so performs the access. If it isn't mapped - a page fault is raised.

Am I getting this straight? i.e. the compiler\runtime library are in charge of allocating virtual memory blocks, and the OS is in charge of a mapping between processes' virtual address and physical addresses (and the paging algorithm that entails)?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

永不分离2024-10-07 05:57:02

大约是对的。不过,内存需要存在于进程的虚拟内存中,以便页面错误实际分配物理页面。您不能只是开始在任何地方探索并期望内核将物理内存放在您碰巧访问的地方。

还有比这更多的事情。阅读 mmap()、匿名与非、共享与私有。还有 brk() 。 malloc() 建立在 brk() 和 mmap() 之上。

About right. The memory needs to exist in the virtual memory of the process for a page fault to actually allocate a physical page though. You can't just start poking around anywhere and expect the kernel to put physical memory where you happen to access.

There is much more to it than this. Read up on mmap(), anonymous and not, shared and private. And brk() too. malloc() builds on brk() and mmap().

流云如水2024-10-07 05:57:02

你差不多已经明白了。您错过的一件事是进程如何首先向系统请求更多虚拟内存。正如托马斯指出的,你不能只写你想要写的地方。操作系统没有理由不能被设计成允许这样做,但如果它知道你将在哪里写入并且你执行操作的空间是连续的,那么它的效率会更高。

在 Unixy 系统上,用户态进程有一个称为数据段的区域,顾名思义:它是数据所在的地方。当进程需要内存来存储数据时,它会调用brk(),要求系统将数据段扩展到指定的指针值。 (例如,如果您现有的数据段为空,而您想将其扩展到 2M,则可以调用 brk(0x200000)。)

请注意,brk()< 虽然很常见,但/code> 不是标准;事实上,它在十年前就被从 P​​OSIX.1 中剔除,因为 C 指定了 malloc() 并且没有理由强制使用该接口进行数据段分配。

You've almost got it. The one thing you missed is how the process asks the system for more virtual memory in the first place. As Thomas pointed out, you can't just write where you want. There's no reason an OS couldn't be designed to allow that, but it's much more efficient if it has some idea where you're going to be writing and the space where you do it is contiguous.

On Unixy systems, userland processes have a region called the data segment, which is what it sounds like: it's where the data goes. When a process needs memory for data, it calls brk(), which asks the system to extend the data segment to a specified pointer value. (For example, if your existing data segment was empty and you wanted to extend it to 2M, you'd call brk(0x200000).)

Note that while very common, brk() is not a standard; in fact it was yanked out of POSIX.1 a decade ago because C specifies malloc() and there's no reason to mandate the interface for data segment allocation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文