21–24 of 24 posts
> 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.
According to the comments on that article, the people still don't understand the basics of virtual memory. "Great article! / Quite shocked to know that windows takes double the kernel memory compared to Linux." "I’m wondering, though, why does the kernel space consume 1gb? That seems like a lot.."
New people are being born all the time!
Earlier 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…
You don't have to relink your userland binaries to do this because they don't contain virtual addresses of kernel data structures, only their own data structures. Expanding the space available for mmap won't force those data structures to move.
You can pretty much load Wine libraries wherever you want; it's pretty rare for a program to break if memory it assumed was unmapped gets used for a library, and programs that break that way will have a lot of trouble when Windows versions change too. Generally programs are only linked with knowledge of where they themselves will be loaded in virtual memory. (Linux ELF shared libraries don't even know that.) All the other addresses are given to the program at startup. It is unusual for Linux binaries to believe that they will be loaded above 2GiB; the usual start address is 0x08048000.
Here's the memory map of a process running under Wine: http://gist.github.com/53853 --- note that there's a lot of Wine and X11 stuff loaded below 2GiB (0x80000000).
Earlier quoted context omitted.
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 :-)
Also, most modern x86 processors have a hack - Physical Address Extension (PAE) - that let the 32-bit processors address up to 64 GB.