develooper Front page | perl.perl5.porters | Postings from June 2012

[perl #107000] Hint-hash copying can leak

Father Chrysostomos via RT
June 29, 2012 00:44
[perl #107000] Hint-hash copying can leak
Message ID:
On Mon Jan 09 09:31:19 2012, nicholas wrote:
> On Sun, Jan 08, 2012 at 04:02:57PM +0000, Dave Mitchell wrote:
> > On Wed, Jan 04, 2012 at 11:14:30PM -0800, Father Chrysostomos via RT
> wrote:
> > > This patch only reduces the number to 3, so we have other things
> > > leaking.  Do failed evals leak in general?  Is that unfixable?  If
> > > that???s the case, it???s probably not worthwhile plugging
> something so rare
> > > as this.
> >
> > failed evals are known to leak OPs during compilation (and this is
> hard to
> > fix). They are not supposed to leak SVs, unless possibly those are
> SVs are
> > attached to OPs.

I had forgotten about this proposal when I started writing a slab
allocator (see c5fb998 and 8be227ab5e).

When I first read it, it wast mostly jargon and I didn’t understand it.

Now that I read it again, I realise I have reinvented it quite closely.
:-)  I even resolved Zefram’s issue about fragmentation by using a free

> I had a hunch that an approach that might work to fix this is to
> a: always use the slab allocator code for OPs

I started with the existing slab allocator but found myself rewriting it

> b: use a new slab when starting each new compilation
>    (and by implication, track if this compilation needs more than one
> slab)

Each op slab is attached to PL_compcv and has an opslab_next pointer,
allowing multiple slabs.

> c: clean up the *slab* if the compilation fails

cv_undef now does that if the CvSLABBED flag is set, but not CvROOT.

> but (b) might increase memory use (ends of partial slabs)
> (although *this* could be avoided by copying OPs during the optimiser,
> which
> could also re-order them to execution order, and drop NULL OPs*)

This I partially solved by making the first slab quite small (about
seven ops), and increasing the size for each subsequent slab.  It could
possibly use some improvement.

> and (c) might require *removing* current checks which attempt to free
> OPs
> on failure, to avoid double frees.

Ops on slabs are now marked as being freed (op_type == OP_FREED).  After
an error, when the slab is cleaned up, those are skipped.

> It strikes me as a big project.

Not as big as the re-eval rewrite. :-)


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