[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150518052453.GT17573@brightrain.aerifal.cx>
Date: Mon, 18 May 2015 01:24:53 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Potential cleanup work post-1.1.9
On Sat, May 02, 2015 at 06:48:18PM -0400, Rich Felker wrote:
> Just some ideas to jot down somewhere public:
>
> - Changing pthread_cancel signal handler to use mcontext_t members by
> name (with the name provided by pthread_arch.h) instead of offset
> macros and a fake overlaid array.
Not yet started.
> - Re-unifying x86_64 and x32 sigsetjmp.s by moving both saved values
> to after the signal mask.
Not yet started. Should be trivial to do.
> - Providing inline atomics instead of runtime-switched for sh4a.
Patch under review; looks ok. More related cleanup work may follow.
> - Cleaning out cruft from struct __pthread, possibly condensing
> multiple locks, packing small/boolean values into chars or
> bitfields, etc.
Not yet started.
> - Evaluating whether it still makes sense to have struct __libc, or
> all the members in it.
I got rid of the locale atomics in __libc that had no purpose but
avoiding TLS access. Nothing else there looks immediately removable,
but here's some analysis:
Presently, the following members are unconditionally needed no matter
what you link; there's no size benefit to factoring them out:
- can_do_threads
- secure
- auxv
- tls_size
- page_size
- global_locale
Of these, page_size could be made optional; it only needs to be stored
on archs that have variable PAGE_SIZE. Of these, global_locale is
pretty large and it would be nice if we could avoid it when not using
functions that depend on locale, but the main thread's __pthread
struct needs a pointer to its active locale and that's always
initialized at startup. And can_do_threads may be useless; it's only
probed correctly on i386 now anyway.
As for other members, here's a summary of where they're used (read,
not updated):
- threaded - sigaction, all functions which create FILEs, synccall
- threads_minus_1 - dynlink, malloc, synccall, __lock
- ofl_head and ofl_lock - fclose, all functions which create FILEs,
stdio exit code
Of these, only the ofl stuff seems practical to move, and it would be
a small savings at best. So for this whole item, I think it makes more
sense to try to gradually phase out members that aren't useful rather
than doing any immediately overhaul or refactoring.
> - Eliminating float code in malloc on soft-float archs.
Moving forward with this requires a way to actually _know_ whether the
target is soft-float. Or we could require the arch to expose a
preferred function for this computation which could theoretically be
independent of whether it's hard- or soft-float.
> - Deduplicating atomic.h emulations of a_* in terms of a_cas, so that
> archs where everything is emulated in terms of a_cas can just define
> a_cas (much like how syscall.h and syscall_arch.h work now).
Prototype sent to list already.
> - Default atomics implementation for new archs to use (at least
> initially) based on __sync_* builtins.
Prototype sent to list already.
> - Bits deduplication.
Still needs to be done. Big task.
> - Possibly eliminating preference of globals over TLS, at least when
> it uglifies/enlarges/complexifies the code, for example use of
> libc.threads_minus_1 to determine whether to skip locks and
> libc.uselocale_cnt (instead of __pthread_self()->locale) in the
> CURRENT_LOCALE macro.
The worst offender, locale stuff, is already fixed. There are probably
some places still checking libc.threads_minus_1 or libc.threaded in
ways that don't actually benefit performance and produce uglier code,
but most places doing this actually have good reason to.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
