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

[perl #121274] sv arenas are never freeded

Thread Next
From:
bulk88 via RT
Date:
March 1, 2014 05:12
Subject:
[perl #121274] sv arenas are never freeded
Message ID:
rt-4.0.18-25646-1393650753-52.121274-15-0@perl.org
On Fri Feb 28 03:30:36 2014, davem wrote:
> 
> Look, if you can come up with a scheme that can detect completely
> empty arenas and free them, that *doesn't* slow down the allocation or
> freeing of each SV, and doesn't have un-perlish random pauses for GC
> sweeps, then I would consider including in core. But I just think for
> the
> reasons I and Zefram mentioned, the reality is that in practice users
> won't see more memory reclaimed very often.

Should I write a GC for http://perl5.git.perl.org/perl.git/blob/HEAD:/lib/less.pm ?

eval "use less 'memory'";

will actually do something. GCing arenas is 1 thing for less 'memory' to do. Another idea I've had was deallocating unused C stack. The perl compiler has horrible C stack recursion during the optimizer phase, and a dozen pages can be shaved off the C stack  (see commented out code at https://rt.perl.org/Ticket/Attachment/1235621/643133/perlmain.c ) and returned to the OS after the compiler returns, one example of C stack https://rt.perl.org/Ticket/Attachment/1064560/528860/plstk1.txt which was made changing VM settings so C stack can't grow beyond whatever was allocated at main(). Whole bug https://rt.perl.org/Ticket/Display.html?id=108276 .

If use less 'memory' runs GC code, then its upto the user to decide when to run the GC and the performance implication with it, not P5P's decision.

-- 
bulk88 ~ bulk88 at hotmail.com

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

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