Malloc timeline.

[Ondřej Bílka]

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.