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

[perl #112312] perl5 version 5.14.2 coredumps during perl -c

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
June 8, 2012 22:39
Subject:
[perl #112312] perl5 version 5.14.2 coredumps during perl -c
Message ID:
rt-3.6.HEAD-5009-1339220352-432.112312-15-0@perl.org
On Sun May 20 01:34:06 2012, davem wrote:
> On Thu, May 17, 2012 at 10:02:39AM -0700, Father Chrysostomos via RT
> wrote:
> > On Wed Apr 25 03:38:30 2012, davem wrote:
> > > I think another suggestion that was mooted a while ago would be to
> > > allocate OPs from a pool or slab, with a new pool/slab started
> each time
> > > we start compiling a new sub, and the pool in some way marked as
> complete
> > > at the end of compiling the sub. On croaking, all the OPs in the
> > > unfinished pools are freed. That way most code doesn't need to be
> > > modified.
> >
> > What exactly is that code at the top of op.c that is compiled only
> when
> > PL_OP_SLAB_ALLOC is defined?
> 
> It's Nick Ing-Simmons's "Experimental" slab allocator for op from
> 1999.
> Its never normally used, apart from, apparently, when
> PERL_IMPLICIT_SYS is
> defined.
> 
> I suspect it would need heavy reworking to make it into a 'one pool
> per CV
> and throw the whole thing away on error' system.

So basically I can just throw the whole thing away and start from
scratch? :-)

Anyway this ‘slab allocation’ is not something I’ve ever done before (my
C experience being limited to what I’ve done with perl).

I *think* you mean something like this:

Every CV can point to a slab, which is allocated much like HvARRAY,
except it can never be reallocked, because there are pointers into it.

The beginning of the slab contains a pointer to the next slab, and so
on, so we never run out.

Freeing a CV consists of calling op_free on every element of each slab
and calling Safefree or PerlMemShared_free (what is the difference
between these two sets of memory functions?) on each slab at the end.

Is that how slabs work, more or less?

What do we do about different op types?  Do we allocate separate slabs
for each op type?  Do we just use the largest and hope the extra padding
that small op structs get isn’t too much of a waste?  Do we allocate a
slab with different parts of the slab set aside for different op sizes
(and flags at the beginning of the slab to indicate how many of each
there are)?

One way to do separate slabs would be to put a flag at the beginning of
each slab to say what it holds, and then just chain them all together.

What should be the default slab size?  64 ops?  That seems a bit small
for, say, DBI, JE, or Parse::RecDescent, but big for people who like
lots of tiny subroutines.  However, it’s probably a good compromise.

Does sizeof(struct op) in C return the padded or unpadded size of the
struct in octets?

To avoid making the xpvcv struct any bigger for XSUBs, we could point
xcv_root to the first slab.  Would that break anything?

Alternatively, we could make sure that the root is the first op in the
first slab, and then use pointer arithmetic xcv_root to get to the
beginning of the slab.

-- 

Father Chrysostomos


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

Thread Previous | 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