How much memory is really allocated?
When you allocate a block of memory on the heap, say:
int* p = new int[1000];
C++ allocates that block, plus a little bit after it that contains information on deleting it later (which is why overwriting is a Bad Thing).
So generally, how much extra is stuck on the end, and what exactly is in the extra info block?
I was under the impression that implementations were more likely to put size information before the block rather than after it. Technically they only need to reserve a size_t, which is 4 bytes. In debug mode you''ll also find some compilers pad both sides of the allocated block with special values so that they can detect overwrites.
[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
depends on the allocator architecture
a heap chunk header could look something like that
also consider that usually a general pourpose allocator has a granularity of 32/64 bytes so everything is at least 32 + sizeof ChunkHeader.
Alberto
-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net
a heap chunk header could look something like that
struct ChunkHeader { int realsize; //size plus overhead int prevoffset; //realtive offset to the previous block in the same page int size; //payload size} also consider that usually a general pourpose allocator has a granularity of 32/64 bytes so everything is at least 32 + sizeof ChunkHeader.
Alberto
-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net
Information up front is usually from 4 to 16 bytes in length on 32bit platforms, with 8 being fairly common. Padding at the end is usually just enough to meet 8 or 16 byte alignment. Taking MSVC as an example (and this is all from memory so there may be small inconsistencies with the way they actually work):
The VC 6 heap uses a 4 byte header and pads up to 8 byte alignment. The header is actually just a pointer to another block of memory private to the allocator. This out of band header holds a pointer back to the original block and a pointer to the header of the block that occurs directly after the original block as well as a couple of status bits.
When run on Win2000 or WinXP the VC runtime sometimes forwards memory allocations to HeapAlloc() which uses a 24 byte header and pads up to a 8 byte alignment. The contents of this header is bizarre and defies description. (At least without access to the operating system source code.) It includes the size of the memory block in qwords, the amount of padding at the end and more flags/status fields than you can shake a stick at. And yes, this is even done with small allocations, so if you request a single byte from malloc() it could have up to 31 bytes of overhead.
The VC 6 heap uses a 4 byte header and pads up to 8 byte alignment. The header is actually just a pointer to another block of memory private to the allocator. This out of band header holds a pointer back to the original block and a pointer to the header of the block that occurs directly after the original block as well as a couple of status bits.
When run on Win2000 or WinXP the VC runtime sometimes forwards memory allocations to HeapAlloc() which uses a 24 byte header and pads up to a 8 byte alignment. The contents of this header is bizarre and defies description. (At least without access to the operating system source code.) It includes the size of the memory block in qwords, the amount of padding at the end and more flags/status fields than you can shake a stick at. And yes, this is even done with small allocations, so if you request a single byte from malloc() it could have up to 31 bytes of overhead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
