Re: Memory management terminology
- From: "Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@xxxxxxxxxxxxxxx>
- Date: Thu, 15 Jun 2006 14:59:23 -0700
<better_cs_now@xxxxxxxxx> wrote in message
news:1150406261.308894.288400@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello all,
I've never gotten a firm grasp on memory mangement in Windows XP, so
I'd like to state my understanding of a few points and see if I am
correct:
1. Page size in Windows XP is 4096 bytes.
For 32 bit Windows on x86, yes. In general, the page size is defined by the
hardware platform.
2. A page is a range of addresses in virtual memory whose start address
is evenly divisible by 4096 (the pgae size).
Yes.
3. Memory is "committed" if there is physical backing (either RAM or
swap space) for it. A synonym for "committed" is "mapped".
Yes.
4. Committing / uncommitting is an operation that is always performed
on a page, not on any smaller or larger chunk of memory.
A page, or range of pages, yes.
5. Swapping in / swapping out is an operation that is always performed
on a page, not on any smaller or larger chunk of memory.
A page or range of pages, yes.
6. Memory allocated with a single call to new / malloc may all reside
in one page or, in the general case, will span multiple pages. Any of
these pages may or may not have physical backing before the allocation.
For a page that does not have physical backing before the allocation, I
believe the following can be said: That page either may or may not be
given physical backing as the result of the allocation. If it is not
given physical backing as a result of the allocation, it will receive
physical backing whenever it is first touched.
A call to new/malloc always returns committed memory. Only VirtualAlloc can
be used to allocate uncommitted pages.
7. Let's supopose I've been allocated a chunk of heap memory that
happens to all fit in one page, and let's also suppose that no other
allocations are a part of that page. When I delete / free that memory,
the involved page may not lose its physical backing even though there's
no real need to keep it around any longer. (Then again, it might also
lose its physical backing.)
True.
Now, I'd also like to ask a couple of questions:
1. Let's suppose that I call delete / free on a block of memory and
that that block of memory is adjacent to a free block. Now, we've got
two free blocks side-by-side. Does the Windows XP memory manager always
immediately coalesce these two free blocks into one free block? Or,
might the coalescing be deferred or perhaps never performed at all?
Undefined. The application may return the memory to the OS, in which case
the page mapping is destroyed, or the application may retain the page in
it's working set for re-use in the future, in which case the page keeps it's
mapping. It's entirely up to the runtime library/OS heap implementation to
make this call. If a physical page is freed as a result of a virtual
mapping being destroyed, that page is, in effect, immediately coalesced with
adjacent free pages. If a virtual page is kept in the working set, it's a
function of the heap implementation as to when, if ever, that page is
coalesced with adjacent free virtual address space. I'd expect that such
coalescence occurs when the page is freed, on a subsequent allocation, or
never. I've never seen anything documenting the actual algorithms used by
the OS (and the C++ runtime), and those algorithms probably differ from one
OS version to the next, and one VC++ version and the next.
2. Is there a succint way to describe the algorithm that determines
when unused pages lose their physical backing?
No, I don't think so.
Thanks very much in advance to anybody that can help on these points /
questions!
-cd
.
- References:
- Memory management terminology
- From: better_cs_now@xxxxxxxxx
- Memory management terminology
- Prev by Date: Re: Memory management terminology
- Next by Date: Re: Memory management terminology
- Previous by thread: Re: Memory management terminology
- Next by thread: Re: Memory management terminology
- Index(es):
Relevant Pages
|
