mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: max_align_t mess on i386
Date: Sat, 14 Dec 2019 10:19:32 -0500	[thread overview]
Message-ID: <20191214151932.GW1666@brightrain.aerifal.cx> (raw)

In reserching how much memory could be saved, and how practical it
would be, for the new malloc to align only to 8-byte boundaries
instead of 16-byte on archs where alignof(max_align_t) is 8 (pretty
much all 32-bit archs), I discovered that GCC quietly changed its
idead of i386 max_align_t to 16-byte alignment in GCC 7, to better
accommodate the new _Float128 access via SSE. Presumably (I haven't
checked) the change is reflected with changes in the psABI document to
make it "official".

This is a somewhat ABI-breaking change (for example it would break ABI
stuct layout for any 3rd party library struct using max_align_t to
align part of a public type), but GCC folks seem to have done the
research at the time to indicate there wasn't anything affected in
practice in known published code.

The big question now is: should we change musl's i386 max_align_t to
follow? One of the advantages of not using compiler-provided headers
is that we don't get this kind of silent ABI change happening out from
under us, or have ABI depend on whether you used GC <=6 vs GCC >=7 to
compile (which is a rather awful property). But it also means we have
to make conscious decisions about following.

I was thinking of trying to make this decision in the next release
cycle (1.2.1) along with merging new malloc, so that we don't
potentially have a single release that drops i386 to 8-byte alignment
followed by one increasing it right back, and making further
combinatoric compat problems. But I realized just now that with time64
already being a hit to ABI-compat between pairs of libc consumers,
changing max_align_t at the same time, if we're going to do it, would
probably be better. FWIW I think this change is *far* less impactful
than time64 in terms of compate.

The disadvantage of changing max_align_t is that we shut out the
possibility of using 8-byte alloction granularity (on i386), which
looks like it could save something like 10-15% memory usage in typical
programs with small allocated objects (see also: Causes of Bloat,
Limits of Health paper[1]), but even up to 33% where the choice is
between 24 and 32 byte allocated slots for a 13-20 byte structure or
string (note: average tends to be half of max if requested sizes are
uniform, but at such small sizes they may tend to be non-uniform).
However, whatever we do with i386, the option of using 8-byte
granularity remains open for all the other 32-bit archs, most of which
tend to be used with machines far more memory-constrained than i386.

The disadvantage of leaving max_align_t alone is that we have to
(continue to) consider _Float128 an unsupported extension type whose
use would be outside the scope of any guarantees we make, and that
would need memalign to use. This is largely viable at present because
it's a fringe thing, but we don't know if that will continue to be
true far in the future.

I'm somewhat leaning towards following the ABI change, because (1) we
have a good opportunity to do it now that we won't get again, and (2)
I'm worried we'll eventually get into a mess by not doing it. But I
want to offer the opportunity for discussion before finalizing
anything, especially in case there are considerations I'm missing.

Rich


[1] https://ftp.barfooze.de/pub/sabotage/tmp/oopsla2007-bloat.pdf


             reply	other threads:[~2019-12-14 15:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-14 15:19 Rich Felker [this message]
2019-12-14 17:51 ` Florian Weimer
2019-12-14 18:17   ` Rich Felker
2019-12-14 18:53     ` Daniel Kolesa
2019-12-15 18:04   ` Rich Felker
2019-12-15  5:47 ` Markus Wichmann
2019-12-15 18:06 ` Jeffrey Walton
2019-12-15 18:22   ` Rich Felker
2019-12-16 15:30     ` Jeffrey Walton
2019-12-16 15:56       ` Rich Felker
2019-12-16 16:36         ` Jeffrey Walton
2019-12-16 17:49           ` Rich Felker
2019-12-16 16:40         ` Florian Weimer
2019-12-16 17:45           ` Rich Felker
2019-12-16 17:49             ` Florian Weimer
2019-12-16 17:51               ` Rich Felker
2019-12-15 18:23   ` Joakim Sindholt
2019-12-15 18:51     ` Rich Felker
2019-12-15 20:03       ` Alexander Monakov
2019-12-15 20:50         ` Szabolcs Nagy
2019-12-15 21:51         ` Jeffrey Walton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191214151932.GW1666@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).