Which allocator to use? For fixed-size, single-thread, pooled allocation?

[collection60]

Hi people,

I am writing a library that will implement a binary file format.

Well... I'm thinking, as a design, it would be nice to have my library
able to promise to not use more than a certain amount of RAM. I could
have a "SetCacheSize(long NewSize);" function. So as part of that
promise, when required memory exceeds that limit, the extra data is
saved to disk and flushed from RAM.

Now to keep that promise, it would be nice to have some control over
the memory management. For example, with malloc, you can't really be
sure of how much RAM is allocated. I'd like to just allocate a block,
say 16MB at first, and then suballocate out of there. I'd also like to
know if I can't allocate from that 16MB (or whatever size it is), so I
can start freeing cached data.

I heard that C++ allocators might be a solution. I've never used
allocators before, but they look promising. For me to use single
allocators, I'd like these qualities.

1) Portable across the main desktop platforms (linux, win32, Mac)
2) Quite fast. Single-threaded is fine if it helps increase speed.
3) Pooled allocation. I pre-define a maximum size that it can allocate
out of, and it allocates out of there. It could pre-allocate the entire
amount, or just allocate in blocks that will never become more than
this limit.
4) Lets me know if we have enough space to allocate another object, or
it's design is simple enough that I can figure out for my self if we
have enough space within the pool. (If not, I'll just flush many
objects to the disk and free up some RAM )
5) Doesn't suck


Any ideas anyone? Like I said, I don't know anything about allocators.

would gcc's "__pool_alloc" do this for me?

 

[collection60]

http://gcc.gnu.org/onlinedocs/libstdc++/20_util/allocator.html

__pool_alloc and __mt_alloc look promising. I don't know which is
better though.

I'm not sure if these compile under CodeWarrior for Mac either...

 

[Mark P]

Hi people,

I am writing a library that will implement a binary file format.

Well... I'm thinking, as a design, it would be nice to have my library
able to promise to not use more than a certain amount of RAM. I could
have a "SetCacheSize(long NewSize);" function. So as part of that
promise, when required memory exceeds that limit, the extra data is
saved to disk and flushed from RAM.

Now to keep that promise, it would be nice to have some control over
the memory management. For example, with malloc, you can't really be
sure of how much RAM is allocated. I'd like to just allocate a block,
say 16MB at first, and then suballocate out of there. I'd also like to
know if I can't allocate from that 16MB (or whatever size it is), so I
can start freeing cached data.

I heard that C++ allocators might be a solution. I've never used
allocators before, but they look promising. For me to use single
allocators, I'd like these qualities.

1) Portable across the main desktop platforms (linux, win32, Mac)
2) Quite fast. Single-threaded is fine if it helps increase speed.
3) Pooled allocation. I pre-define a maximum size that it can allocate
out of, and it allocates out of there. It could pre-allocate the entire
amount, or just allocate in blocks that will never become more than
this limit.
4) Lets me know if we have enough space to allocate another object, or
it's design is simple enough that I can figure out for my self if we
have enough space within the pool. (If not, I'll just flush many
objects to the disk and free up some RAM )
5) Doesn't suck


Any ideas anyone? Like I said, I don't know anything about allocators.

would gcc's "__pool_alloc" do this for me?

I don't have a lot to add here, but I'll mention that "allocators" are
specifically objects used by standard library containers for dynamic
memory allocation. This is generally only a subset of the total memory
allocations of a program. For more general control you'll probably also
need to at least redefine operator new to use a custom memory allocator.
And this does nothing for memory usage of "stack" objects.

 

[collection60]

I don't have a lot to add here, but I'll mention that "allocators" are

specifically objects used by standard library containers for dynamic
memory allocation. This is generally only a subset of the total memory
allocations of a program. For more general control you'll probably also
need to at least redefine operator new to use a custom memory allocator.
And this does nothing for memory usage of "stack" objects.

Thanks Mark.

I won't be using operator new at all, though, or virtual functions
even. Just allocatoring RAM and then redefining it to the correct class.

 

[tragomaskhalos]

Hi people,

I am writing a library that will implement a binary file format.

Well... I'm thinking, as a design, it would be nice to have my library
able to promise to not use more than a certain amount of RAM. I could
have a "SetCacheSize(long NewSize);" function. So as part of that
promise, when required memory exceeds that limit, the extra data is
saved to disk and flushed from RAM.

[allocator stuff snipped]

Any ideas anyone? Like I said, I don't know anything about allocators.

IMO this seems overengineered in the extreme. Your code can use a fixed
buffer allocated according to the NewSize parameter via "buffer = new
unsigned char[NewSize]" or whatever and just use that, why do you want
to do anything more complicated than that ?
Like other posters have intimated, allocators are fiddly beasts that
have their uses, but are you sure you're not someone who's just found
out about these neat things called "hammers" and now thinks that your
library looks like a nail ?

 

[collection60]

Any ideas anyone? Like I said, I don't know anything about allocators.

IMO this seems overengineered in the extreme. Your code can use a fixed
buffer allocated according to the NewSize parameter via "buffer = new
unsigned char[NewSize]" or whatever and just use that, why do you want
to do anything more complicated than that ?

I guess because allocating out of my own buffer, means I must now do my
own memory management. So, let's say that my structs take up 48 bytes.
So now I must allocate 48 bytes
out of that big block. Then I must manage the free blocks. I'm now
doing my own memory management.

I've tried this sort of thing before it's a total pain.

Although I was doing variable size allocation. Perhaps the trauma of
trying to get variable size allocation before (writing my own malloc
almost) put me off fixed size allocators? Are you saying that making
your own fixed size code to allocate is easy?

Like other posters have intimated, allocators are fiddly beasts that
have their uses, but are you sure you're not someone who's just found
out about these neat things called "hammers" and now thinks that your
library looks like a nail ?

I'm still trying to understand the hammer!