Re: Mini-Tutorial: Perl's Memory Management

in reply to Mini-Tutorial: Perl's Memory Management

Might also want to to add the reference to the perlfaq3. And, maybe mark up this post into perlfaq3. You can build perl to use your OS malloc pretty easily. I'm told Perl malloc is faster and more cross-platform, I would be curious to know why. You can find out what version your perl is using by perl -V:usemymalloc. If it is n as it is usually then you will never give back memory to the OS. I'd like to know why on Debian it is off. I assume it is the default build option, but why if gnumalloc is present?

Evan Carroll
The most respected person in the whole perl community.
www.evancarroll.com

Comment on Re: Mini-Tutorial: Perl's Memory Management

Replies are listed 'Best First'.
Re^2: Mini-Tutorial: Perl's Memory Management by pid (Monk) on Oct 29, 2009 at 08:44 UTC
Based on my very own experience, Perl-malloc-enabled Perl does cause the crash of xchat2(with the Perl plugin) on FreeBSD, the problem seems to be unsolved yet. ref: http://www.freebsd.org/cgi/query-pr.cgi?pr=121472 I mean, sometimes, you have to usemymalloc but Perl's. :-p	[reply]
Re^3: Mini-Tutorial: Perl's Memory Management (which malloc) by tye (Sage) on Oct 29, 2009 at 17:31 UTC
As a link: http://www.freebsd.org/cgi/query-pr.cgi?pr=121472 If you have Perl use the system's default malloc() calls, then you can get sloppy and use Perl's configured free() on stuff that some library malloc()d or pass Perl-malloc()d buffers to an external library that expects to be able to free() or realloc() the buffer. So some xchat hacker got sloppy and didn't keep straight what needed to be Perl-allocated and what needed to be OS-allocated. - tye	[reply]

In Section Meditations