gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > new / delete

#47790 - Mucca - Wed Jul 13, 2005 4:31 pm

Hello
we're currently in the process of overloading new and delete, using malloc and free, but some of the behaviour of malloc is confusing us, and I was wondering if anyone has some links to proper documentation (gcc 2.9.5, been looking, me no successful) as to what exactly malloc does. For instance, malloc clearly writes the size (plus 5 or 9) allocated in the four bytes preceeding the space allocated, however the value written there is not exactly the size of the object allocated - more specifically it seems to always be either 5 or 9 larger than the size allocated. Whether it is 5 or 9 is to do with whether malloc allocates an extra four bytes after the space requested. Perhaps there's a compiler flag to prohibit the allocation of these four extra bytes (It could waste a lot of memory when you've got up to 3000 dynamically allocated objects). Finally, what malloc writes directly after the allocated space (including the 4-byte extra piece) is some kind of marker for malloc. Anyone know the format of this marker? This isnt especially important for us, but it interests me nonetheless.

Oh, and Im not really looking for an answer along the lines of "Don't dynamically allocate memory of gba, its teh baddd!". Just looking for documentation, or even source code of malloc if such a thing is available.

Please
.
.
.
Pretty please
.
.
.
with sugar on top

#47792 - sajiimori - Wed Jul 13, 2005 5:33 pm

malloc is part of the C library so the details depend on which library you are using. The standard library is not part of GCC.

The extra memory may partly be for alignment, but some extra space will always be needed for book keeping. You can reduce overhead by making fewer allocations, e.g. by allocating a block of objects as a pool and then constructing individual objects within that. This is what some STL containers do, notably std::vector and std::deque.

#47799 - Mucca - Wed Jul 13, 2005 7:27 pm

Well it seems malloc (in the library that we are using) doesn't like allocating sizes which are not a multiple of 8 bytes. Therefore, any space allocated which is not evenly divisible by 8 will have four unused bytes allocated after it, and thus the size written to the four bytes before the space will be 9 larger than the actual size passed to malloc, as opposed to 5 larger when it does divide evenly (why 5 I'm still not sure).

The marker is still a little confusing but not really important.

Are there any compiler flags to stop the "multiple of 8" allocation? Is there a good reason for it (speed? reduces fragmentation?)? And shouldn't there be some kind of standards for the implementation of new and malloc? Eg under windows and Visual Studio, malloc will return NULL if no memory is available on the heap, whereas under our setup for gba, malloc will happily allocate addresses above 0x0203ffff, thus I believe overwriting other areas due to the mirroring of memory. Can this behaviour perhaps be controlled with the link script where the stack and heap are defined? Naturally exceptions are out of the question. Oh well.

#47800 - Miked0801 - Wed Jul 13, 2005 7:41 pm

Malloc of larger blocks is a speed/size optimization. Malloc will also (I believe) store a header just ahead or behind each chunk of memory you request. This is a lits structure for it's own use. We do something similiar here :)

Write your own wrapper for malloc that bounds checks the malloc return if you don't like its behavior or write your own :)

#47801 - sajiimori - Wed Jul 13, 2005 7:45 pm

Quote:
Are there any compiler flags to stop the "multiple of 8" allocation?
As I said, it's part of the libarary, not the compiler. I don't know your library's reason for doing 8 byte alignment, but larger allocation units often reduce the overhead from bookkeeping.
Quote:
And shouldn't there be some kind of standards for the implementation of new and malloc?
Not really. Implementation details should be free to change based on the needs of different platforms and applications. If I don't like glibc's malloc, I can use a different one.
Quote:
Eg under windows and Visual Studio, malloc will return NULL if no memory is available on the heap, whereas under our setup for gba, malloc will happily allocate addresses above 0x0203ffff, thus I believe overwriting other areas due to the mirroring of memory. Can this behaviour perhaps be controlled with the link script where the stack and heap are defined?
Possibly. The standard does specify that malloc should return null on failure, so your enviornment isn't meeting that requirement.
Quote:
Naturally exceptions are out of the question.
Are they? Well, I wouldn't want to use them on GBA anyway because failure is generally end-of-story -- no late recovery for ROM failures and such. The game either works or it doesn't, eh? :)