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:40
Re: [patch 0/3] rework sv.c body-inventory mechanics
Message ID:
On Sat, Jan 30, 2010 at 7:13 AM, Nicholas Clark <> wrote:
> 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.
> Nicholas Clark

In a recent thread:
Seeking clues re subtle change in behaviour under NYTProf

Tim was seeking a way to privatize the arenas under its allocations.
You outlined how to push and pop PL_sv_arenaroot to/from the
savestack as a way to create a new empty arena that would then
provide the bodies for the SVs that NYTProf needs.

You also expressed concerns about reliability and the lack of API.
IMO these patches begin to address
both issues:

- any private arenas created as you outlined are
essentially lost to perl, as PTEs are currently, after
Storable::freeze() is done with them (unless another freeze() is
needed).  release_arenas(), or something like it, is needed to reclaim

- get_arena()  and release_arenas() provide a balanced
API in the RAII sense; you return what you borrow.
There are perhaps issues with inadequate use of return-codes, errs,
etc, but the basic usage is (imo) self-evident.

That we dont already clean up after ourselves (and let
the OS do it for us) is lazy.  Mostly thats a virtue,
but there are certainly cases where its a false one.


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