Klaus Bonadt said:
Thus, each process is able to allocate 2GB at maximum. Indeed, I can almost
allocate 2GB with my test program, allocating chunks of 1MB.
However, when my crucial application runs out of memory, Task Manager tells
that there is only 1,6GB in use (see my first mail).
That's why I think there's fragmentation at work. Imagine the
pathological scenario: your whole memory is occupied by 1K allocated
chunk followed by 1023K free chunk, and so on. 1024 such pairs will eat
up 1GB of RAM in a way that only 1MB is actually used, but you cannot
allocate another 1MB chunk. It's an artificial example of course, it's
highly unlikely to occur in practice, but it demonstrates the idea of
fragmentation nicely.
Furthermore, starting
my test program at this point in time, this program is able to allocate
further 1,2 GB until my whole virtual memory is allocated.
Your test program is a separate process that has its own address space.
Remember - you are not running out of physical RAM, you are running out
of addresses to map it to. Each process has its very own 4GB address
space, independent of any other process. Physical RAM gets mapped to a
process' address space on as-needed basis.
By the way, with Windows virtual memory management, you cannot fragment
physical memory at all, you can only fragment virtual address space. The
way it works, all physical memory is broken into pages 4KB (on some
systems 8KB) large. So is virtual memory. When a region of virual memory
is allocated, each page of virtual memory is backed by a page of
physical memory. Now, virtual addresses within this region need to be
consequtive (because your program expects the address arithmetic to
work), but physical RAM pages don't need to be. The system just picks
free RAM pages lying around and maps them to virtual pages. Moreover, if
the system runs out of RAM, it picks a physical page (mapped to some
virtual page in some process A), saves its contents to disk and reuses
it for another virtual page possibly in a different process B. If
process A later needs to refer to that virtual page, some other physical
page may be assigned to it and contents read back from disk.
Bottom line: there is no permanent attachment of virtual addresses to
physical RAM pages, and there is no requirement that a contiguous
stretch of virtual addresses be backed by a contiguous stretch of
physical addresses. Thus RAM cannot become fragmented, but virtual
address space can.
I have the AMD 64 processor, but I need a special 64-bit XP system, which is
not yet available for AMD, correct?
Sorry, I don't know.
What are PVIEW and Task Manager showing, the sum of heap sizes (including
unused space due to fragmentation) or the sum of actual allocated memory
(HeapAlloc) which was not freed afterwards?
I believe they show a working set, which is memory that is a) actually
allocated and b) actually loaded in RAM, rather than being swapped to
hard drive. Well, in your case of huge amounts of RAM available, you can
assume that a working set is very close to actual RAM consumption. They
don't show the unused space, because it is, well, unused.
I guess the first case, which means the sum of memory which is reserved for
the process even the process is not able to allocate due to
fragmentation?
If this were the case, they would always show 2GB - that's the amount of
address space given to every process. Such a display would be pretty
useless, don't you think?
--
With best wishes,
Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken