hi everyone,
in which situations HeapAlloc or VirtualAlloc will be used in our program.
i have no experience of these functions but seem in many programs of others.
where to use these functions in my code means where are they benefited in my code.
plz guide me in which situations i use these two different kind of functions and their related one's.
plz guide me according to ur experience where r they more fitted in situations like:?:
in which situations HeapAlloc or VirtualAlloc will be used in our program.
i have no experience of these functions but seem in many programs of others.
where to use these functions in my code means where are they benefited in my code.
plz guide me in which situations i use these two different kind of functions and their related one's.
plz guide me according to ur experience where r they more fitted in situations like:?:
Hi,
In situations where you are allocating under 4MB of memory it really makes little difference which you use, over 4MB and you should be using VirtualAlloc.
Donkey
In situations where you are allocating under 4MB of memory it really makes little difference which you use, over 4MB and you should be using VirtualAlloc.
Donkey
Also, if you need to execute from memory you're allocating (ie, you're constructing code at runtime), you'll need VirtualAlloc and specifying EXECUTE access for the memory, otherwise you'll get crashes on NX-enabled CPUs.
HeapAlloc have a few minor "extra" abilitys on the WinXP and Win2k3.
Those are
"Low-fragmentation Heap"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/low_fragmentation_heap.asp
and
Serialization
Serialization ensures mutual exclusion when two or more threads attempt to simultaneously allocate or free blocks from the same heap. There is a small performance cost to serialization, but it must be used whenever multiple threads allocate and free memory from the same heap. Setting the HEAP_NO_SERIALIZE value eliminates mutual exclusion on the heap. Without serialization, two or more threads that use the same heap handle might attempt to allocate or free memory simultaneously, likely causing corruption in the heap.
And also VirtualAlloc have some *magic* too, for instance; if you need more than 4GB memory in your 32-bit application, you need VirtualAlloc.
VirtualAlloc can reserve pages which is declared by AWE fuctions ( ok, I couldn't build that sentence correctly :( :( )
But here is some explations about that
Address Windowing Extensions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/address_windowing_extensions.asp
Those are
"Low-fragmentation Heap"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/low_fragmentation_heap.asp
and
Serialization
Serialization ensures mutual exclusion when two or more threads attempt to simultaneously allocate or free blocks from the same heap. There is a small performance cost to serialization, but it must be used whenever multiple threads allocate and free memory from the same heap. Setting the HEAP_NO_SERIALIZE value eliminates mutual exclusion on the heap. Without serialization, two or more threads that use the same heap handle might attempt to allocate or free memory simultaneously, likely causing corruption in the heap.
And also VirtualAlloc have some *magic* too, for instance; if you need more than 4GB memory in your 32-bit application, you need VirtualAlloc.
VirtualAlloc can reserve pages which is declared by AWE fuctions ( ok, I couldn't build that sentence correctly :( :( )
But here is some explations about that
Address Windowing Extensions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/address_windowing_extensions.asp
The only other memory allocation function that you need to be concerned about is GlobalAlloc, it is not useful in a general sense as the heap and virtual functions perform much better. However, because of Microsoft's obsession with backward compatibility you will require it on occasion for clipboard functions, that is allocating and de-allocating memory for use by the Windows clipboard.
I used to use globalalloc for all memory allocation
I've always found globalalloc to be a little stange in its behavior
Sometimes it doesnt return the requested memory, but if you
attempt to alloc more than previously requested it'll give to it you!!
If anyone can explain this id like to know why.
thx
ps. nowadays I tend to use heapalloc.
I've always found globalalloc to be a little stange in its behavior
Sometimes it doesnt return the requested memory, but if you
attempt to alloc more than previously requested it'll give to it you!!
If anyone can explain this id like to know why.
thx
ps. nowadays I tend to use heapalloc.
I've always found globalalloc to be a little stange in its behavior
Sometimes it doesnt return the requested memory, but if you
attempt to alloc more than previously requested it'll give to it you!!
*perhaps*, and this is just a wild guess, it does heap compaction upon a failed memory alloc?
Would be interesting to do a heap walk before and after a failed alloc... but I guess it's a bit hard to reproduce failure situation reliably?
PS: On NT, Global/LocalAlloc basically call HeapAlloc, just with "a magic flag" specified. Apart from the clipboard situation (and other cases where PSDK says you need G/Lalloc), there's really no reason not to use HeapAlloc instead.
Also, if you need to execute from memory you're allocating (ie, you're constructing code at runtime), you'll need VirtualAlloc and specifying EXECUTE access for the memory, otherwise you'll get crashes on NX-enabled CPUs.
you could also virtualprotect the heapalloc'd memory.. works same way, and avoids the dep issue on nx enabled pc's
Also, if you need to execute from memory you're allocating (ie, you're constructing code at runtime), you'll need VirtualAlloc and specifying EXECUTE access for the memory, otherwise you'll get crashes on NX-enabled CPUs.
you could also virtualprotect the heapalloc'd memory.. works same way, and avoids the dep issue on nx enabled pc's
You'll end up marking more than just your own memory block eXecutable that way, though... at least unless you alloc enough memory to fix both alignment and range issues. And then you might as well just use VirtualAlloc, since it's easier :)