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

From Tomas Vondra
Subject Re: PATCH: two slab-like memory allocators
Date
Msg-id 0b14e90b-1985-bb04-0261-2fcdc28755ab@2ndquadrant.com
Whole thread Raw
In response to Re: PATCH: two slab-like memory allocators  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: PATCH: two slab-like memory allocators
List pgsql-hackers
Attached is v6 of the patch series, fixing most of the points:

* common bits (valgrind/randomization/wipe) moved to memdebug.h/c

Instead of introducing a new header file, I've added the prototypes to
memdebug.h (which was already used for the valgrind stuff anyway), and
the implementations to a new memdebug.c file. Not sure what you meant by
"static inlines" though.

So the patch series now has three parts - 0001 with memdebug stuff, 0002
with slab and 0003 with gen (still a poor name).

* removing AllocSet references from both new memory contexts

* using FLEXIBLE_ARRAY_ELEMENT in SlabContext

* using dlist instead of the custom linked list

I've however kept SlabContext->freelist as an array, because there may
be many blocks with the same number of free chunks, in which case moving
the block in the list would be expensive. This way it's simply
dlist_delete + dlist_push.

* use StandardChunkHeader instead of the common fields

* removing pointer to context from block header for both contexts

* fix format in FreeInfo/AllocInfo (including for AllocSet)

* improved a bunch of comments (bitmap size, chunksPerBlock formula)

* did a pgindent run on the patch

* implement the missing methods in Gen (Stats/Check)

* fix a few minor bugs in both contexts

I haven't done anything with hiding pointers behind typedefs, because I
don't know what's so wrong about that.

I also haven't done anything with the bitmap access in SlabAlloc - I
haven't found any reasonable case when it would be measurable, and I
don't expect this to be even measurable in practice.

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: "Ideriha, Takeshi"
Date:
Subject: DECLARE STATEMENT setting up a connection in ECPG
Next
From: Craig Ringer
Date:
Subject: Re: 9.6 TAP tests and extensions