Re: MemPools rewrite

On Wed, 18 Oct 2000, Andres Kroonmaa wrote:

> search for right pool based on ptr would have much less overhead
> with chunks than it would be with current Pools. This could even
> be considered.

Still prohibitively expensive, in general, IMO.
 
> hmm, how does compiler handle struct:
> struct {
> char b;
> double x;
> struct {
> int i;
> short s;
> char c;
> double y;
> }
> }
> does it really reorder them?

No, it usually pads (adds extra space where needed).

> malloc is known to return 8-aligned pointers.

Not exactly. Malloc returns pointers aligned for any data type (maximum
alignment, that can be, say, 16 bytes)). Man malloc:

        "The allocated space is suitably aligned (after
        possible pointer coercion) for storage of any type
        of object. If the space is at least pagesize bytes
        in length (see getpagesize((3)),) the returned
        memory will be page boundary aligned as well."

> If there is an array of
> struct above, does compiler add alignment overhead between items?

No. Items themselves are padded, see above.

> Then it should account for that in sizeof() also, right? But then
> chunked pools get created with right objsizes also.

Sizeof() accounts for padding within a single structure. Henrik's trick
with pointer arithmetic is probably safer for arrays. The two may be
equivalent, but I am not sure (and would not rely on it).

If you use the right size/offsets, chunks will work, _provided_ you do
not prepend each chunk with some housekeeping information of arbitrary
size. I am not saying you add that information now, but somebody may be
tempted to do it later.

Note that the above requires access to data type at the time of pool
creation which is a problem if pools as in lib/ (can be solved with
macros, I guess).

> btw, does "double" need to be aligned only on 64-bit cpus?

I do not know.
 
Alex.
Received on Wed Oct 18 2000 - 16:20:54 MDT