This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Malloc timeline.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Allan McRae <allan at archlinux dot org>, libc-alpha at sourceware dot org
- Date: Tue, 17 Dec 2013 16:22:24 +0100
- Subject: Re: Malloc timeline.
- Authentication-results: sourceware.org; auth=none
- References: <20131217120834 dot GA29241 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1312171406200 dot 10125 at digraph dot polyomino dot org dot uk>
On Tue, Dec 17, 2013 at 02:17:52PM +0000, Joseph S. Myers wrote:
> On Tue, 17 Dec 2013, Ondrej Bilka wrote:
>
> > The most ugrent step for 2.19 is announce which features will not be
> > supported (malloc_set_state, malloc hooks...), for these we should
> > prepare a copy of current allocator as separate library.
>
> I don't think "as separate library" makes sense here. I don't think glibc
> should be in the business of shipping multiple malloc libraries. If a
> feature is to be supported, it should be supported in the default malloc
> in libc. If not, it still needs to be supported for existing binaries
> forever, although compat symbols may prevent new binaries from using it.
>
For malloc_set_state it is a sanest solution.
> > Could somebody review features and write which are needed and which are
> > not?
>
> If you want to remove a feature from malloc you should do the analysis of
> existing users (using the various tools out there for searching large
> amounts of free software source code). There's also the option of marking
> interfaces with __attribute_deprecated__, putting a prominent note in the
> NEWS file about the proposal to desupport them for new binaries, and
> waiting for GNU/Linux distributions to do rebuilds to see what the impact
> of the change is (this may mean waiting several months for such feedback).
>
Which needs to be gathered for 2.19.
As I said before its malloc_set_state and hooks. For hooks a common
suggestion is to write functions that intercept malloc and use
dlsym(RTLD_NEXT), I will prepare patch for that.
Then there are various libraries that come with malloc which depend on
implementation but could be decoupled.
> In addition, anyone wishing to remove features from malloc should work
> with users to find better alternatives for any problematic features.
> Thus, you should work directly with the Emacs development community to
> understand their requirements for which they use malloc_get_state /
> malloc_set_state, so as to develop a better alternative that Emacs can use
> in future that doesn't cause problems for changing malloc's internal
> datastructures. malloc_get_state / malloc_set_state can't be turned into
> compat symbols until Emacs is no longer using them.
>
Like using a portable unexec from xemacs?
http://www.us.xemacs.org/Architecting-XEmacs/unexec.html
This did not happened in ten years, I could try to suggest that.
A simplest solution is to provide a separate allocator for emacs that
supports malloc_set_state like I wrote above.