Game Server Programming : MemoryPool : Memory Alignment

Hi guys

My Email: jakezhang1989@hotmail.com
My GitHub Link

Thank you for taking time to go through this post from which you would get what you want.
If you have any problems or opinions that are different form mins, please email me or leave a comments. I will reply as soon as possible.

OK, Let us get started!

---

SGI STL Supports

1. Allocator interface in the C++ standard
2. Its own customized Default Allocator.

---

SGI Default Allocator

default allocator maintains its own free lists for small objects.It uses an underlying system-provided allocator both to satisfy larger requests, and to obtain larger chunks of memory which can be subdivided into small objects.

Alloc obtains memory from malloc

Malloc is used as the underlying system-provided allocator. Malloc has the advantage that it allows for predictable and simple failure detection. ::operator new would have made this more complicated given the portability and thread-safety constraints

---

Alloc does not free all memory

Memory allocated for blocks of small objects is not returned to malloc. It can only be reused by subsequent alloc::allocate requests of (approximately) the same size.

Thus programs that use alloc may appear to leak memory when monitored by some simple leak detectors. This is intentional.

The primary design criterion for alloc was to make it no slower than the HP STL per-class allocators, but potentially thread-safe, and significantly less prone to fragmentation.
Like the HP allocators, it does not maintain the necessary data structures to free entire chunks of small objects when none of the contained small objects are in use.
This is an intentional choice of execution time over space use. It may not be appropriate for all programs. On many systems malloc_alloc may be more space efficient, and can be used when that is crucial.

SGI free all memory when the last container disappears, which is typically just before program exit.
In most environments, this would be highly counterproductive [adj.反生产的；使达不到预期目标的] because free would typically have to touch many long unreferenced pages just before the operating system reclaims them anyway.
It would often introduce a significant delay on program exit, and would possibly page out large portions of other applications.
we recommend that leak detection tests be run with malloc_alloc instead of alloc. This yields more precise results with GC-based detectors (e.g. Pure Atria’s Purify), and it provides useful results with detectors that simply count allocations and deallocations.

---

No Attempt to sort free lists

The default allocator makes no special attempt to ensure that consecutively allocated objects are “close” to each other, i.e. share a cache line or a page.
A deallocation request adds an object to the head of a free list, and allocations remove the last deallocated object of the appropriate size.
Thus allocation and deallocation each require a minimum number of instructions.

---

Deallocate requires size argument

This choice also removes some time overhead in the important special case of fixed-size allocation. In this case, the size of the object, and thus the address of the free-list header becomes a clearly recognizable compile-time constant.