This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The direction of malloc?


On Mon, Dec 16, 2013 at 01:46:07PM -0800, Roland McGrath wrote:
> > The main purpose of malloc_get_state / malloc_set_state is for use by 
> > emacs.  If emacs adopted a better approach I'd happily deprecate them - 
> > turn them into compat symbols - but you still need to support them 
> > indefinitely with existing emacs binaries, as a matter of binary 
> > compatibility.  (Support could mean such binaries - binaries using the 
> > malloc_set_state compat symbol - use a different copy of malloc in libc 
> > from what all other binaries use, if necessary.)
> 
> (I believe I've mentioned this before when discussing the ppc32 ABI
> situation.)  I'm pretty sure that the way Emacs uses malloc before dumping
> is such that there's no significant amount of allocation done then (if any)
> that will ever be freed later.  So for ABI compatibility it is probably
> sufficient to have a malloc_set_state call from an old binary result in the
> allocations made up to that point becoming unfreeable.  For correctness,
> free in the new library would have to identify the given block as being
> from the old regime and not do anything bad.  (Conceivably this could even
> be done just with a compat symbol version for free, though probably there
> are ways things will go wrong if the current-version free does bad things
> when given a pointer from the old-version allocator.)  But it doesn't need
> to be able to actually do anything worthwhile, like recover that memory for
> future use, return it to the system, or ensure a double-free is detected.

Thanks, this simplifies a situation considerably. If we also a do not
extract free space then we only need to detect old-style pointers.

If a new implementation uses sentinel then I could do this with zero
performance impact for programs that do not use malloc_set_state. It
suffices to place odd sentinels where prev_size used to be, unless there is
corruption new-style pointers have this odd but a old style ones have that even.

You need this to support realloc as you need to know old size.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]