Front page | perl.perl5.porters |
Postings from March 2014
On Fri, Feb 28, 2014 at 09:12:33PM -0800, bulk88 via RT wrote:
> 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 ?
I'm really not convinced of its utility.
> eval "use less 'memory'";
Why the 'eval'? Are you proposing that each 'use' this module triggers a
one-off GC sweep? Or that code within the scope of "use less 'memory'"
triggers occasional sweeps, e.g. at scope exit?
If the former, then this seems to be a misuse of the semantics of a pragma.
> 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
The best thing to do here is to avoid the recursion in the first place. If
the scheme to have the last op_sibling point back to the parent works out
for 5.21, then removing recursion from the depth-first tree walks of
Perl_scalarvoid() etc becomes trivial. Removing recursion from the op_next
chain walking of Perl_rpeep() is more problematic. I've put a mechanism in
place that reduces the likelihood of recursion being needed, but it still
recurses in pathological examples.
> 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.
No one's stopping anyone from putting up a CPAN module that does this.
--
Overhead, without any fuss, the stars were going out.
-- Arthur C Clarke
Thread Previous
|
Thread Next