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

From Andres Freund
Subject Re: [HACKERS] PATCH: two slab-like memory allocators
Date
Msg-id 20170227174201.yrofai7neyp6shb2@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] PATCH: two slab-like memory allocators  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] PATCH: two slab-like memory allocators  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On 2017-02-27 12:27:48 -0500, Tom Lane wrote:
> 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.

Yea, I hadn't yet realized when writing that that termite actually,
despite running on ppc64, compiles a 32bit postgres.  Will thus
duplicate StandardChunkHeader's contents in to slab.c :( - I don't see
an easy way around that...



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Creation of "Future" commit fest, named 2017-07
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Creation of "Future" commit fest, named 2017-07