--without-bash-malloc

[Greg Schafer]

Hi Guys

I am reluctantly adding `--without-bash-malloc' to the Bash build. Bottom
line is this: it results in a smaller Bash binary and allows Bash to compile
in more scenarios.

Once upon a time, back when LFS used to statically link the whole of the
Temptools phase, a statically linked Bash would often crash (somewhere
inside Bash malloc) when it was installed as /bin/sh and was used to
configure Binutils. Back then I suggested `--without-bash-malloc' as a
workaround.

LFS later started defaulting to this switch (in the dynamic link case) as a
workaround for getting Bash-2.05b to compile with GCC-3.4.x. Then someone
claimed it gave Bash a performance improvement. It's true that it's not hard
to contrive a test case (eg: loop doing something 10,000 times) that proves
Bash is a fraction faster when compiled using this switch.

Note that the current LFS explanation is clearly bogus:

"This option turns off the use of Bash's memory allocation (malloc) function
which is known to cause segmentation faults. By turning this option off,
Bash will use the malloc functions from Glibc which are more stable."

As of this writing, Fedora use the switch but Debian do not. In August 2004,
I emailed Bash maintainer Chet Ramey about the issue and here is what he
said:

----------------------------------------
>Just a quick question if you don't mind. Why does bash use its own malloc
>under Linux? Modern Glibc already provides a reasonably good malloc.

It's very fast, it doesn't waste as much memory as it used to, it's
reasonably well-tuned for bash, and it has extensive debugging features.

>Fedora have started to configure their bash `--with-bash-malloc=no' Other
>Linux distros still seem to use the default of bash malloc.

That's certainly Red Hat's option.  One would hope they did some
performance analysis before doing so.
----------------------------------------

It's also worth noting that it's currently impossible to statically link
recent Bash against recent Glibc (unless --without-bash-malloc is used). See
here for example:

  http://lists.gnu.org/archive/html/bug-bash/2005-11/msg00025.html

As an aside, these days there is little doubt that smaller code size often
results in better performance. This is because the gap between memory and
modern CPU cache speeds continues to widen and cache misses become more
costly. Please see this doc for some analysis:

  http://people.redhat.com/wcohen/ncsu2004/

Regards
Greg