Re: x*alloc optimizations

Re: x*alloc optimizations

[Michael Meissner]

| law@cygnus.com (Jeffrey A Law) writes:
|
| > I quickly scanned your patch for any problems this creates, but didn't
| > find any.  However, we should probably fix xrealloc to avoid losing if
| > a zero sized request is made.
|
| But please fix this system dependent.  I.e., add a configure test for
| this non-ISO C behaviour and don't let normal systems do the same work
| twice (since their realloc implementation again checks for NULL).

This is an unneeded micro-optimization.  I would rather burn the 2-3
instructions for every xmalloc call than add a bunch of configure support and
ifdefs to complicate the code.  Especially for Canadian crosses where you can't
test the behavior of the runtime system.  Another problem is that when GCC
configured it, malloc/calloc/realloc behaved in one fashion, but when the user
put the binary compiler on his/her system, the system malloc in the shared
library now behaves differently.

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: x*alloc optimizations

[Jim Meyering]

Michael Meissner <meissner@cygnus.com> writes:
| This is an unneeded micro-optimization.  I would rather burn the 2-3
| instructions for every xmalloc call than add a bunch of configure support and
| ifdefs to complicate the code.  Especially for Canadian crosses where you can't
| test the behavior of the runtime system.  Another problem is that when GCC
| configured it, malloc/calloc/realloc behaved in one fashion, but when the user
| put the binary compiler on his/her system, the system malloc in the shared
| library now behaves differently.

I admit it may not be worth it, but it can be done without
complicating the code.  Uses of *alloc functions don't change
at all, and the only ifdefs I added (when I did this for fileutils)
were in the replacement lib/*alloc.c functions.  The m4 tests assume
*alloc are broken when cross compiling.

Re: x*alloc optimizations

[Richard Henderson]

On Wed, May 20, 1998 at 12:29:19PM -0700, Ulrich Drepper wrote:
> Come on!  This is no arbitrary test.  This is the test for ISO C
> compliance and no vendor will dare to make an compliant library
> suddenly uncompliant.

No, Mike has a point.  The issue is not that one would suddenly make
the library non-compliant, but that a compiler built for OS version
X.Y.1 might not work on X.Y.0 because it was the .1 that fixed the ISO bug.


r~

Re: x*alloc optimizations

[Michael Meissner]

| Michael Meissner <meissner@cygnus.com> writes:
| | This is an unneeded micro-optimization.  I would rather burn the 2-3
| | instructions for every xmalloc call than add a bunch of configure support and
| | ifdefs to complicate the code.  Especially for Canadian crosses where you can't
| | test the behavior of the runtime system.  Another problem is that when GCC
| | configured it, malloc/calloc/realloc behaved in one fashion, but when the user
| | put the binary compiler on his/her system, the system malloc in the shared
| | library now behaves differently.
|
| I admit it may not be worth it, but it can be done without
| complicating the code.  Uses of *alloc functions don't change
| at all, and the only ifdefs I added (when I did this for fileutils)
| were in the replacement lib/*alloc.c functions.  The m4 tests assume
| *alloc are broken when cross compiling.

While linux gnulibc{1,2} may or may not change the behavior of malloc, I have
witnessed this at OSF, where one revision of OSF/1 had malloc do one behavior
(crash on NULL pointer to realloc or return NULL, I forget which), and the next
revision did another behavior (return unique pointer).  I as supplier of
compiler binaries then would have my releases not work, if I built the compiler
on one revision, and had users on the other revision tried to use the
compiler.  Depending on a configure test for malloc/realloc behavior is utterly
dangerous for providers of binary software.

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: x*alloc optimizations

[Ulrich Drepper]

Michael Meissner <meissner@cygnus.com> writes:

> There are loads of uncomplaint systems.

Agreed, and this is what Jim's macros are testing for.  I commented on
your comment that relying on realloc(NULL,size) is unsafe since some
vendor might change the behaviour.

> Also ISO C has two different behaviors (return NULL or return a
> unique pointer).  If you test for one, a system vendor may change
> his/her implementation to do the other behavior without breaking ISO
> C conformance.

But this isn't what we are testing for.  This is uninteresting here.
All the macros do is to test whether

	realloc(NULL, size) == malloc(size)

as demanded by ISO C and the "worst" which could happen is that one
more vendors sees the light and changes the non-ISO C behaviour.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: x*alloc optimizations

[Ulrich Drepper]

Michael Meissner <meissner@cygnus.com> writes:

> I as supplier of compiler binaries then would have my releases not
> work, if I built the compiler on one revision, and had users on the
> other revision tried to use the compiler.  Depending on a configure
> test for malloc/realloc behavior is utterly dangerous for providers
> of binary software.

Come on!  This is no arbitrary test.  This is the test for ISO C
compliance and no vendor will dare to make an compliant library
suddenly uncompliant.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: x*alloc optimizations

[Michael Meissner]

| Michael Meissner <meissner@cygnus.com> writes:
|
| > I as supplier of compiler binaries then would have my releases not
| > work, if I built the compiler on one revision, and had users on the
| > other revision tried to use the compiler.  Depending on a configure
| > test for malloc/realloc behavior is utterly dangerous for providers
| > of binary software.
|
| Come on!  This is no arbitrary test.  This is the test for ISO C
| compliance and no vendor will dare to make an compliant library
| suddenly uncompliant.

There are loads of uncomplaint systems.  Also ISO C has two different
behaviors (return NULL or return a unique pointer).  If you test for one, a
system vendor may change his/her implementation to do the other behavior
without breaking ISO C conformance.

Re: x*alloc optimizations

[Jim Meyering]

Jeffrey A Law <law@cygnus.com> writes:

|   In message < r2af8fzfwu.fsf@happy.cygnus.com >you write:
|   > law@cygnus.com (Jeffrey A Law) writes:
|   >
|   > > I quickly scanned your patch for any problems this creates, but didn't
|   > > find any.  However, we should probably fix xrealloc to avoid losing if
|   > > a zero sized request is made.
|   >
|   > But please fix this system dependent.  I.e., add a configure test for
|   > this non-ISO C behaviour and don't let normal systems do the same work
|   > twice (since their realloc implementation again checks for NULL).
| The amount of time saved by this optimization is likely to be so
| small that it's dwarfed by the time to write an autoconf test make
| sure it does the right thing, and get it checked in.  :-)
|
| IMHO, it's not worth the effort.

In case anyone decides to do this, you don't have to
write the autoconf tests;  I already did it for fileutils:

  ftp://alpha.gnu.org/gnu/fileutils-3.16n.tar.gz

see these files:

  lib/malloc.c
  lib/realloc.c
  m4/malloc.m4
  m4/realloc.m4

I don't know if it was worth the effort, but I'm happier :-)

Re: x*alloc optimizations

[Jeffrey A Law]

  In message < r2af8fzfwu.fsf@happy.cygnus.com >you write:
  > law@cygnus.com (Jeffrey A Law) writes:
  > 
  > > I quickly scanned your patch for any problems this creates, but didn't
  > > find any.  However, we should probably fix xrealloc to avoid losing if
  > > a zero sized request is made.
  > 
  > But please fix this system dependent.  I.e., add a configure test for
  > this non-ISO C behaviour and don't let normal systems do the same work
  > twice (since their realloc implementation again checks for NULL).
The amount of time saved by this optimization is likely to be so
small that it's dwarfed by the time to write an autoconf test make
sure it does the right thing, and get it checked in.  :-)

IMHO, it's not worth the effort.

jeff

Re: x*alloc optimizations

[Ulrich Drepper]

law@cygnus.com (Jeffrey A Law) writes:

> I quickly scanned your patch for any problems this creates, but didn't
> find any.  However, we should probably fix xrealloc to avoid losing if
> a zero sized request is made.

But please fix this system dependent.  I.e., add a configure test for
this non-ISO C behaviour and don't let normal systems do the same work
twice (since their realloc implementation again checks for NULL).

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: x*alloc optimizations

[Jeffrey A Law]

  In message < 19980516145345.A680@dot.cygnus.com >you write:
  > Two things.  
  > 
  >   (1) Since we define xrealloc, we can trust it to do the right thing
  >       when given a NULL initial argument.  
  > 
  >   (2) Using calloc instead of malloc+bzero can be more efficient.  At
  >       least glibc's calloc knows that space newly acquired from the
  >       system is already zero.  This is particularaly relevant to the
  >       large memory blocks gcc tends to allocate during optimization.
The only potential problem I see is xrealloc doesn't check for a zero
length size parameter like xmalloc (and the new xcalloc).

I quickly scanned your patch for any problems this creates, but didn't
find any.  However, we should probably fix xrealloc to avoid losing if
a zero sized request is made.

Otherwise it looks fine to me.

jeff

x*alloc optimizations

[Richard Henderson]

Two things.  

  (1) Since we define xrealloc, we can trust it to do the right thing
      when given a NULL initial argument.  

  (2) Using calloc instead of malloc+bzero can be more efficient.  At
      least glibc's calloc knows that space newly acquired from the
      system is already zero.  This is particularaly relevant to the
      large memory blocks gcc tends to allocate during optimization.


r~