This is the mail archive of the glibc-bugs@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]

[Bug malloc/6527] [powerpc] Malloc alignment insufficient for PowerPC


http://sourceware.org/bugzilla/show_bug.cgi?id=6527

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 7 Feb 2014, jouko.orava at iki dot fi wrote:

> > The most recently discussed suggestion for dealing with malloc_get_state / 
> > malloc_set_state is that malloc_set_state should mark all previous 
> > allocations as unfreeable
> 
> I'm sure emacs users will love that feature.
> 
> I'd thought that a slow path that uses e.g. separate metadata pool, so that it
> can trivially (but slowly) support any alignment, would have been a more
> sensible approach. After all, most users I know would prefer slower operation
> to out of memory errors. Most Linux distributions do not have user limits that
> would stop a memory-hogging userspace application from triggering the OOM
> killer. (Or didn't it come up what would happen if the malloc_get_state() -
> malloc_set_state() cycle would be repeated a few times?)

It was asserted that malloc_set_state is only called very early in emacs 
startup and no significant amount of the previously allocated memory gets 
freed anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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