Submit more articles like this one and less Web 2.0 gossip please.
Anatomy of a Program in Memory
11–20 of 24 posts
Re: Anatomy of a Program in Memory
#12Earlier quoted context omitted.
As narag says, it's only recently that this has become an issue. When physical memory size was orders of magnitude smaller than than the address space, it didn't matter that the kernel carved out 1GB of address space for itself. User applications still had the other 3GB, which was far more than any system had physical memory. It's only during this limbo period when 4GB of RAM is relatively cheap, yet there are still…
From the way I read those comments, I gathered that the comments implied that Windows "consumed" two gigs of ram, where as Linux took 1 gig. I thought there was a dissonance between how people understood "virtual memory," which is essentially a mapping function, to "memory," which people assume to be the physical ram.
It's easy to make that mistake at first, but it is a very important distinction. Most of the time, for most processes, most of that space is unallocated. However, since it's basically impossible to change the size of the kernel area without relinking the process binaries, and since that area is shared between all processes, the size of that area has to remain fixed.
It is interesting that Linux and NT differ. Perhaps this is due to the fact that NT needs more kernel memory to house, e.g. the windowing system, whereas Linux systems put X in userspace? I'm speculating here.
Something I never considered: that design difference probably makes Wine's job easier, because between the 2GB and 3GB marks is a region of memory the Windows process assumes is inaccessible, yet in Linux is in userspace. They could (and probably do) load the Wine libraries here without interfering with the Windows process. It also means that it would be very difficult to implement Wine's complement, a way of running Linux binaries on Windows.
Re: Anatomy of a Program in Memory
#13I'd like to understand what's being described in this article, but unfortunately I lack the necessary educational background. Does anyone have any links to other resources that will allow me to better understand what is being discussed in this post?
This article is already a very high level description of Linux memory management (specifically on 32 bit Intel processors). If you want to move down to lower levels of abstraction and learn more details, then keep reading that blog! On the other hand, if you want a less technical description of these concepts then I'm not sure where to look.
Re: Anatomy of a Program in Memory
#14Earlier quoted context omitted.
From the way I read those comments, I gathered that the comments implied that Windows "consumed" two gigs of ram, where as Linux took 1 gig. I thought there was a dissonance between how people understood "virtual memory," which is essentially a mapping function, to "memory," which people assume to be the physical ram.
It's easy to make that mistake at first, but it is a very important distinction. Most of the time, for most processes, most of that space is unallocated. However, since it's basically impossible to change the size of the kernel area without relinking the process binaries, and since that area is shared between all processes, the size of that area has to remain fixed. It is interesting that Linux and NT differ. Perhaps…
It's pretty arbitrary really. It's rare to need more than 2 gigs of memory in a single user process. On the other hand, the more address space you have in the kernel the easier it is to use spare memory for IO buffer caching.
Re: Anatomy of a Program in Memory
#15Earlier quoted context omitted.
As narag says, it's only recently that this has become an issue. When physical memory size was orders of magnitude smaller than than the address space, it didn't matter that the kernel carved out 1GB of address space for itself. User applications still had the other 3GB, which was far more than any system had physical memory. It's only during this limbo period when 4GB of RAM is relatively cheap, yet there are still…
From the way I read those comments, I gathered that the comments implied that Windows "consumed" two gigs of ram, where as Linux took 1 gig. I thought there was a dissonance between how people understood "virtual memory," which is essentially a mapping function, to "memory," which people assume to be the physical ram.
From the way I read those comments, I gathered that the comments implied that Windows "consumed" two gigs of ram,
I'm afraid I didn't make myself clear before. I also think that commenters were wrong. I just tried to explain why. The article says that's the default arrangement, but if non-kernel memory grows bigger than 2 GB, I assume that it'll be allocated in the virtual space that's unused by kernel.
Re: Anatomy of a Program in Memory
#16Earlier quoted context omitted.
Address space is not much bigger than physical memory now for 32 bits. I've read that my laptop could in fact have 4GB instead of the nominal 3GB. So even if the memory is not "consumed", the default must be changed at run time, unless the kernel space literally consumes 2/3 of available memory.
Given you don't reference what operating system is in use, you're probably using Microsoft Windows here. The implementation of virtual memory has common traits, but details vary by OS and even OS version. Physical address space and virtual address space are two different aspects of system design, and it is completely feasible to have these values be the same, or to have either of the two be larger than the other. Yes…
I really don't understand. At home I've got an Asus F6V. At work it's Asus G50V. Both with Vista/Kubuntu dual boot. I really don't know what's happening with 32/64 bits here. Both use 32 bits OSs but G50V (64 bit machine) has 4GB, so it seems it isn't OS the piece that decides memory addressing capabilities :-)
Re: Anatomy of a Program in Memory
#17> This helps prevent pointer bugs, though not as effectively as avoiding C in the first place.
I hate to sound like the average Reddit poster and write something like "quoted for truth", but... quoted for truth.
Re: Anatomy of a Program in Memory
#18I'd like to understand what's being described in this article, but unfortunately I lack the necessary educational background. Does anyone have any links to other resources that will allow me to better understand what is being discussed in this post?
CPUs prior to 386 had direct access to physical memory. From 386 on, you could enable protected mode (default for Linux and Windows 95+) in which a pointer doesn't point to a physical location but to a virtual address that system translates to physical memory or disk-cached memory. That's the most basic fact. With much luck, that's the only thing you need to know to understand it :-)
Re: Anatomy of a Program in Memory
#19if you're interested in the security aspects of this stuff, there are a number of presentations by openbsd developers on the openbsd site (http://openbsd.rt.fm/papers/):
Re: Anatomy of a Program in Memory
#20I'd like to understand what's being described in this article, but unfortunately I lack the necessary educational background. Does anyone have any links to other resources that will allow me to better understand what is being discussed in this post?
Virtual memory is part of the fields of computer architecture and operating systems; popular textbooks are Computer Architecture: A Quantitative Approach and Modern Operating Systems.
http://books.google.com/books?id=pqYl3SWkA64C http://books.google.com/books?id=tqtZGQAACAAJ