Re: [HACKERS] PATCH: two slab-like memory allocators
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] PATCH: two slab-like memory allocators |
Дата | |
Msg-id | 20170227174201.yrofai7neyp6shb2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] PATCH: two slab-like memory allocators (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] PATCH: two slab-like memory allocators
|
Список | 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 по дате отправления: