This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Abolish STRANGE_MALLOC. Now all malloc()s are considered strange :-)
authorNicholas Clark <nick@ccl4.org>
Wed, 20 Feb 2013 20:38:33 +0000 (21:38 +0100)
committerNicholas Clark <nick@ccl4.org>
Fri, 22 Feb 2013 14:24:11 +0000 (15:24 +0100)
commitc035e214a7cbc7943b3315dec7384717e7e9947c
treeb748519c2ad5cb2658c2b745965e72b2c74a42e0
parentc319391ae00610ef5c07296498178b0777a48912
Abolish STRANGE_MALLOC. Now all malloc()s are considered strange :-)

STRANGE_MALLOC was added in 5.002 beta 1 (4633a7c4bad06b47) as part of an
work around for typical mallocs, which had a bad interaction with perl's
allocation needs. Specifically, repeatedly extending an array and then
creating SV heads (such as when reading lines of a file into an array)
could end up with each reallocation for the array being unable to extend in
place, needing a fresh chunk of memory, and the released memory not being
suitable for use as more SV heads, so sitting unused. The solution was for
perl to recycle the old array body as SV heads, instead of returning it to
the system, passing the memory from the the AV code to the SV code using
offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size.

STRANGE_MALLOC was actually a signal that the malloc() didn't need
protecting from itself, and to disable the work around.

offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size were removed by
commit 9a87bd09eea1d037 in Nov 2010, without any ill effects, hence the
code used when STRANGE_MALLOC was *not* defined is essentially doing extra
work for no benefits.

From the lack of problems reported, one can assume that in the intervening
15 years malloc technology has got significantly improved, and it is probably
better to be honest with it, rather than trying to second guess it.

Hence remove all the non-STRANGE_MALLOC code, and leave everyone using the
much simpler code. See also
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-11/msg00495.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2013-01/msg00126.html
av.c
hv.c