In order PERL_EMERGENCY_SBRK to have effect you should use Perl's malloc, which doesn't look like a good idea to me.And you make this claim based on what exactly? From the install file:
=head2 Malloc Issues
Perl relies heavily on malloc(3) to grow data structures as needed,
so perl's performance can be noticeably affected by the performance of
the malloc function on your system. The perl source is shipped with a
version of malloc that has been optimized for the typical requests from
perl, so there's a chance that it may be both faster and use less memory
than your system malloc.
However, if your system already has an excellent malloc, or if you are
experiencing difficulties with extensions that use third-party libraries
that call malloc, then you should probably use your system's malloc.
(Or, you might wish to explore the malloc flags discussed below.)
=over 4
=item Using the system malloc
To build without perl's malloc, you can use the Configure command
sh Configure -Uusemymalloc
or you can answer 'n' at the appropriate interactive Configure prompt.
Note that Perl's malloc isn't always used by default; that actually
depends on your system. For example, on Linux and FreeBSD (and many more
systems), Configure chooses to use the system's malloc by default.
See the appropriate file in the F<hints/> directory to see how the
default is set.
In reply to Re^2: Monitoring the death of oversized Perl processes
by JavaFan
in thread Monitoring the death of oversized Perl processes
by arthurg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |