From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tv@fuzzy.cz>
cc: Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>,
        pgsql-committers <pgsql-committers@postgresql.org>,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: pgsql: Generational memory allocator
In-reply-to: <ce281fac-b6f5-2d86-a9eb-4cc04d5d4bce@fuzzy.cz>
References: <E1eHa4J-0006hI-Q8@gemulon.postgresql.org>
 <20171123001649.y2nf7422iay6cw3v@alap3.anarazel.de>
 <CANP8+jKoT=Pg5W_3FcKiDf+FMrJhFYacxt_g5E0=tkmb5s8M6g@mail.gmail.com>
 <20171123193936.fncfnar5wkpx56mw@alap3.anarazel.de>
 <21043.1511467602@sss.pgh.pa.us>
 <c09b1f12-8042-1e77-1b3e-ca68a2b44167@fuzzy.cz>
 <20171123214636.unwkrkunr7m2bkii@alap3.anarazel.de>
 <13547.1511474676@sss.pgh.pa.us>
 <ce281fac-b6f5-2d86-a9eb-4cc04d5d4bce@fuzzy.cz>
Comments: In-reply-to Tomas Vondra <tv@fuzzy.cz>
	message dated "Thu, 23 Nov 2017 23:51:03 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31254.1511497154.1@sss.pgh.pa.us>
Date: Thu, 23 Nov 2017 23:19:14 -0500
Message-ID: <31255.1511497154@sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tv@fuzzy.cz> writes:
> On 11/23/2017 11:04 PM, Tom Lane wrote:
>> I pushed a patch that computes how much padding to add and adds it.
>> (It might not really work if size_t and void * are different sizes,
>> because then there could be additional padding in the struct; but
>> that seems very unlikely.)

> Thanks. Do we need to do something similar to the other memory contexts? 
> I see Slab does not do this at all (assuming it's not necessary), and 
> AllocSet does this in a different way (which seems a bit strange).

Hm ... the coding in AllocSet is ancient and I have to say that I don't
like it as well as what I put into generation.c.  We could not have done
it in that way at the time, because (IIRC) we did not have constant macros
for SIZEOF_SIZE_T, and maybe not SIZEOF_VOID_P either --- and you need
constant macros in order to do the #if calculation, because sizeof() does
not work in preprocessor expressions.  But we have 'em now, so I'm tempted
to change aset.c to match generation.c.

As for SlabChunk, I think that's fine as-is (except I wonder why the
"block" field is declared "void *" rather than "SlabBlock *").  Since
the contents are fixed at two pointer fields, it's impossible that
there's any unexpected padding in there --- the struct size is
basically guaranteed to be 2 * sizeof(pointer).  Which makes it either 8
or 16 bytes, either one of which is certain to be a multiple of MAXALIGN.
So I think the StaticAssert that that's true is plenty sufficient in
that case.

			regards, tom lane