Re: VirtualAlloc()
- From: "Alex Blekhman" <xfkt@xxxxxxxxx>
- Date: Thu, 21 Dec 2006 20:26:41 +0200
"Chris Kushnir" wrote:
Well, I always have been using VirtualAlloc() for
large/global memory usage instead of "new". I only use
"new" inside functions. Because VirtualAlloc() can
allocate physical storage (either in RAM or on disk).
Whoever told you that was wrong. How do you think `new'
allocates memory? As any other allocation function it
uses `VirtualAlloc' (either directly or indirectly).
However, by avoiding `new' you miss many useful checks.
Like memory leaks, in your case, for example.
The real question is: Why do you need `VirtualFree'
instead of regular `new'?
new (in VC++) eventually calls malloc, which may
eventually call HeapAlloc, which may eventually manipulate
memory reserved/committed by VirtualAlloc. There are a
number of reasons to use Virtual*(), just as there are for
Heap*(), just as there are for malloc, just as there are
for new. Granted, most apps don't need to go beyond
new/malloc, but knowing how/when/why to use the
Heap/Virtual API's can give some apps significant (speed)
improvements.
All this is nice, but original poster didn't provide enough
info to decide whether VirtualAlloc is appropriate or not.
Using VirtualAlloc in order to allocate large portion of
memory can be justified sometimes, but such occasions are
rare. Representing VirtualAlloc as an alternative to new
because it allegedly allocates global memory (whatever it
is) or can allocate physical storage, or more stable than
regular `new' is utter nonsense. VirtualAlloc doesn't
allocate global memory; control over physical storage, which
VirtualAlloc provides is indirect and close to none.
Once memory is committed by the Heap*() API is is not
de-committed until the heap is destroyed (or the app
exits). Temp allocation of large objects using new (and
through it Heap*()) could cause the process heap to expand
it's committed use to the point that other apps on the
system need to page more frequently until the app exits.
There is also the issue of heap fragmentation.
Clearly, original poster prefers VirtualAlloc over `new' not
because of heap fragmentation.
`VirtualAlloc' has nothing to do with allocation physical
storage. That's why it's called "Virtual", after all. You
cannot allocate physical storage from user mode code. OS
will use physical storage at its discretion in order to
back up virtual allocations that your application makes.
I expect the OP was talking about the ability to control
the committment of pages directly via Virtual*().
You are correct in that the OS (usually) decides whether a
committed page is in physical memory or paged out to a
paging file.
You are misleading in that Virtual*() does allow you to
committ pages, and does provide some measure of direct
memory allocation via AWE (IIRC AWE memory is never paged
out).
OP's code doesn't mention AWE anywhere. Moreover, AWE isn't
available for Win9x/Me anyway. Op says that he uses
VirtualAlloc on Win9x/Me platforms because it's more
"stable" than `new'.
.
- Follow-Ups:
- Re: VirtualAlloc()
- From: Chris Kushnir
- Re: VirtualAlloc()
- References:
- VirtualAlloc()
- From: William
- Re: VirtualAlloc()
- From: Alex Blekhman
- Re: VirtualAlloc()
- From: William
- Re: VirtualAlloc()
- From: Alex Blekhman
- Re: VirtualAlloc()
- From: Chris Kushnir
- VirtualAlloc()
- Prev by Date: Re: Where is $(VCInstallDir) defined ?
- Next by Date: Re: Where is $(VCInstallDir) defined ?
- Previous by thread: Re: VirtualAlloc()
- Next by thread: Re: VirtualAlloc()
- Index(es):
Relevant Pages
|