classification
Title: Remove dummy member in GCHead
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.8
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: gregory.p.smith, methane, pitrou, serhiy.storchaka, tim.peters, twouters
Priority: normal Keywords:

Created on 2018-05-21 00:23 by methane, last changed 2018-05-21 20:05 by gregory.p.smith. This issue is now closed.

Messages (7)
msg317212 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2018-05-21 00:23
https://github.com/python/cpython/commit/e348c8d154cf6342c79d627ebfe89dfe9de23817

> We can probably get rid of the double and this union hack all together today.
> That is a slightly more invasive change that can be left for later.

Can we do it for now (Python 3.8)?
msg317226 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-05-21 10:04
From the linked changeset message:

> unless anyone knows of a platform where ssize_t is 4 bytes?

That's most 32-bit platforms, right?  Basically, size_t and ssize_t are pointer-sized except on some rare architectures.

> A more correct non-hacky alternative if any alignment issues are still found would be to use a compiler specific alignment declaration on the structure and determine which value to use at configure time.

AFAIU, the problem is not alignment of the PyGC_Head structure (it's always sufficiently aligned for its pointer-sized members) but alignment of the user-defined object that follows it.

The underlying issue IMO is we're trying to force a one-size-fits-all alignment for user-defined object structs that we know nothing about (but might contain something like a "long double" or, worse, some SIMD values).  Perhaps PyTypeObject should grow a `tp_alignment` field.
msg317228 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-05-21 10:17
Short of adding a `tp_alignment`, though, I think we should not make things harder for the common cases.  This means we should probably keep the "double" member to ensure that extension types that have a "double" field in their object struct have the right alignment by default.  "long double" is much rarer and people who need it can workaround alignment issues by hand (for example by issuing memcpy() calls).
msg317235 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2018-05-21 14:20
Make sense.

Then, what about using anonymous struct to make GC code more readable?

 typedef union _gc_head {
     struct {
         union _gc_head *gc_next;
         union _gc_head *gc_prev;
         Py_ssize_t gc_refs;
-    } gc;
+    };
     double dummy;  /* force worst-case alignment */
 } PyGC_Head;

All code like g->gc.gc_next will be like g->gc_next.
msg317236 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-05-21 14:23
I'm fine with an anonymous struct.  Is it standard C these days?
msg317237 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2018-05-21 14:23
Oh,,, while even gcc 4.0 supported it, it is language spec from C11, not C99.
msg317238 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2018-05-21 14:45
I grepped quickly and I can't find existing usage of anonymous union/struct.
History
Date User Action Args
2018-05-21 20:05:10gregory.p.smithsetnosy: + twouters
2018-05-21 14:45:15methanesetstatus: open -> closed
resolution: rejected
messages: + msg317238

stage: resolved
2018-05-21 14:23:55methanesetmessages: + msg317237
2018-05-21 14:23:19pitrousetmessages: + msg317236
2018-05-21 14:20:11methanesetmessages: + msg317235
2018-05-21 10:17:22pitrousetmessages: + msg317228
2018-05-21 10:04:59pitrousetnosy: + tim.peters, gregory.p.smith, serhiy.storchaka
messages: + msg317226
2018-05-21 00:23:25methanecreate