Archived

This topic is now archived and is closed to further replies.

How much memory is really allocated?

This topic is 5018 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
depends on the allocator architecture
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites