develooper Front page | perl.perl5.porters | Postings from January 2010

Re: [patch 0/3] rework sv.c body-inventory mechanics

Thread Previous | Thread Next
Jim Cromie
January 31, 2010 10:23
Re: [patch 0/3] rework sv.c body-inventory mechanics
Message ID:
On Sat, Jan 30, 2010 at 9:51 AM, Reini Urban <> wrote:
> 2010/1/30 Nicholas Clark <>:
>> On Wed, Jan 27, 2010 at 06:30:09PM -0700, Jim Cromie wrote:
>>> these patches add a request-id to the body-parts allocation chain
>>> ie to:
>>> new_body, del_body macros,
>>> S_more_bodies()
>>> get_arena()
>>> In principle, this change will allow perl to track
>>> each user of get_arena(), such that we can (later) reclaim it.
>> I'm really not sure what outstanding problem this is solving.
>> It seems to add complexity, rather than simplifying.
> Sure. There's one more tag per body.

To be more precise, theres an additional param in the
body-parts allocation chain (3 calls), but no added fields in an SV.
This will have some small increased cost, 99% of it residing
in the (new|del)_body.* macros, S_more_bodies and get_arena
are called ~1000x less often.

> But as I understand it, Jim wants to improve the performance of
> release_arenas().

You've come to the crux of it.
release_arenas() doesnt actually exist now, so its performance is
arguably zero, hopefully going to 1 soon.

> I'm dying to see the new release_arenas() code and the benchmark.

benchmarking presents some problems; its very much like
benchmarking a program with PERL_DESTRUCT_LEVEL=2 vs 0,
there will be a cleanup cost in the former thats not seen in the latter.

the real issue is what new features it may support:

- early reclaim of PTEs.

When Storable::freeze() is used to create ~/.cpan/Metadata,
~2**19 (iirc) PTEs are created, then freed back to PL_bodyroots[x],
but this free-list hangs out til process termination.
Surely we have better things to do with that memory than
to save it JUST IN CASE we need to freeze another dataset.

- segregated allocation

Tim Bunce was recently asking for private-arenas to support NYTProf.
My view is you dont really have a proper private-arenas facility
until you can recycle them.

Conceivably, a routine populating a data structure could push
fresh/empty freelists into the interpreter, and then
all allocations made by the routine or its callees would be made from
known arenas.  In the extreme case,
the sv-typed arenas could be sized such that ALL allocs
done in the routine would fit in one arena each.
This could be useful in somewhat esoteric situations.

- use less memory
  early PTE cleanup qualifies as one tool with benefits

> --
> Reini Urban

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About