Re: bitfield and gcc

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: Gaetano Mendola <mendola(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: bitfield and gcc
Date: 2012-02-15 17:03:24
Message-ID: CA+TgmobgAsO+8aP7=j4NF-4SSo8jqvxRRr+O-5FNr0Oa0uE4xw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 13, 2012 at 5:38 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola <mendola(at)gmail(dot)com> wrote:
>> I wonder if somewhere in Postgres source "we" are relying on the GCC
>> "correct behaviour" regarding the read-modify-write of bitfield in
>> structures.
>
> Probably not. I'm pretty sure that we don't have any bitfields, since
> not all compilers are happy with them. And it looks like this behavior
> doesn't affect other kinds of struct fields.

We do, actually: see spgist_private.h, itemid.h, regis.h, spell.h, and
ts_type.h. And maybe some others.

I'm not aware, however, of any cases where we put a lock in the same
structure as a bitfield, so I think we might be OK in that regard.
But the bit about <64-bit spinlocks next to other stuff is a bit
alarming. I continue to be astonished at the degree to which the gcc
developers seem not to care about the POLA. Padding out all of our
spinlocks to 64 bits would not be free: it would cost us significantly
in memory usage, if nothing else. I understand that it's not possible
to modify individual bits in a bitfield atomically, but generating a
64-bit-wide read-modify-write when the underlying base type is 4 bytes
or less is almost pure evil, IMHO.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-02-15 17:20:37 pgsql: Speed up in-memory tuplesorting.
Previous Message Fujii Masao 2012-02-15 16:52:15 Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)