Re: [HACKERS] PATCH: two slab-like memory allocators - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] PATCH: two slab-like memory allocators
Date
Msg-id 12622.1488216468@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] PATCH: two slab-like memory allocators  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] PATCH: two slab-like memory allocators  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> The best theory I have so far that I have is that slab.c's idea of
> StandardChunkHeader's size doesn't match what mcxt.c think it is
> (because slab.c simply embeds StandardChunkHeader, but mcxt uses
> MAXALIGN(sizeof(StandardChunkHeader))).  That's not good, but I don't
> quite see how that'd cause the issue, since StandardChunkHeader's size
> should always be properly sized.

Uh, wrong.  On a 32-bit machine with debug enabled, StandardChunkHeader
will contain 3 4-byte fields.  However, there are some such machines on
which MAXALIGN is 8.  For example, looking at termite's configure
output:

checking size of void *... 4
checking size of size_t... 4
checking size of long... 4
checking alignment of short... 2
checking alignment of int... 4
checking alignment of long... 4
checking alignment of long long int... 8
checking alignment of double... 8

axolotl's output looks similar.  I expect my old HPPA dinosaur
will show the failure as well.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] PATCH: two slab-like memory allocators
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Write Ahead Logging for Hash Indexes