develooper Front page | perl.perl5.porters | Postings from February 2014

[perl #121274] sv arenas are never freeded

Thread Previous | Thread Next
From:
bulk88 via RT
Date:
February 27, 2014 17:36
Subject:
[perl #121274] sv arenas are never freeded
Message ID:
rt-4.0.18-13607-1393522606-1105.121274-15-0@perl.org
On Thu Feb 27 09:09:47 2014, davem wrote:
> On Wed, Feb 26, 2014 at 11:35:09PM -0800, bulk88 via RT wrote:
> > To address what I think will be the response. Processing each data
> > file/task in a fork is not a solution. It is a bandaid to a design bug
> > in Perl. Perl should be able to goto 1 or 2 GB of memory to process a
> > huge data set, then scale back down to, below, 150% of the memory usage
> > before the task/data set job began. Not stay at 1 GB or 400% even though
> > all variables/data belonging to the task were freed on a PP level.
> 
> But that is likely to be almost entirely down to the system's malloc()
> implementation rather than perl's SV arena usage.

No, AFAIK perl's SV arena usage never calls free on any arena blocks until interp exit. So this memory usage  has nothing to do with malloc implementation since free() was never called on it. Calling free() is perl's domain, not libc's.

> 
> Yes, perl will keep SV head and bodies around for future use

Forever? That is a leak.

> but it
> free()s any PVX() structures etc. If the system's malloc() can consolidate
> and unmap() freed chunks, then good for it. But that's outside our
> control.
> 

This bug isn't about PVX buffers. None were allocated in the sample XS code in this ticket.

-- 
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121274

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About