CV-based slab allocation for ops

This addresses bugs #111462 and #112312 and part of #107000.

When a longjmp occurs during lexing, parsing or compilation, any ops
in C autos that are not referenced anywhere are leaked.

This commit introduces op slabs that are attached to the currently-
compiling CV.  New ops are allocated on the slab.  When an error
occurs and the CV is freed, any ops remaining are freed.

This is based on Nick Ing-Simmons’ old experimental op slab implemen-
tation, but it had to be rewritten to work this way.

The old slab allocator has a pointer before each op that points to a
reference count stored at the beginning of the slab.  Freed ops are
never reused.  When the last op on a slab is freed, the slab itself is
freed.  When a slab fills up, a new one is created.

To allow iteration through the slab to free everything, I had to have
two pointers; one points to the next item (op slot); the other points
to the slab, for accessing the reference count.  Ops come in different
sizes, so adding sizeof(OP) to a pointer won’t work.

The old slab allocator puts the ops at the end of the slab first, the
idea being that the leaves are allocated first, so the order will be
cache-friendly as a result.  I have preserved that order for a dif-
ferent reason:  We don’t need to store the size of the slab (slabs
vary in size; see below) if we can simply follow pointers to find
the last op.

I tried eliminating reference counts altogether, by having all ops
implicitly attached to PL_compcv when allocated and freed when the CV
is freed.  That also allowed op_free to skip FreeOp altogether, free-
ing ops faster.  But that doesn’t work in those cases where ops need
to survive beyond their CVs; e.g., re-evals.

The CV also has to have a reference count on the slab.  Sometimes the
first op created is immediately freed.  If the reference count of
the slab reaches 0, then it will be freed with the CV still point-
ing to it.

CVs use the new CVf_SLABBED flag to indicate that the CV has a refer-
ence count on the slab.  When this flag is set, the slab is accessible
via CvSTART when CvROOT is not set, or by subtracting two pointers
(2*sizeof(I32 *)) from CvROOT when it is set.  I decided to sneak the
slab into CvSTART during compilation, because enlarging the xpvcv
struct by another pointer would make all CVs larger, even though this
patch only benefits few (programs using string eval).

When the CVf_SLABBED flag is set, the CV takes responsibility for
freeing the slab.  If CvROOT is not set when the CV is freed or
undeffed, it is assumed that a compilation error has occurred, so the
op slab is traversed and all the ops are freed.

Under normal circumstances, the CV forgets about its slab (decrement-
ing the reference count) when the root is attached.  So the slab ref-
erence counting that happens when ops are freed takes care of free-
ing the slab.  In some cases, the CV is told to forget about the slab
(cv_forget_slab) precisely so that the ops can survive after the CV is
done away with.

Forgetting the slab when the root is attached is not strictly neces-
sary, but avoids potential problems with CvROOT being written over.
There is code all over the place, both in core and on CPAN, that does
things with CvROOT, so forgetting the slab makes things more robust
and avoids potential problems.

Since the CV takes ownership of its slab when flagged, that flag is
never copied when a CV is cloned, as one CV could free a slab that
another CV still points to, since forced freeing of ops ignores the
reference count (but asserts that it looks right).

To avoid slab fragmentation, freed ops are marked as freed and
attached to the slab’s freed chain (an idea stolen from DBM::Deep).
Those freed ops are reused when possible.  I did consider not reusing
freed ops, but realised that would result in significantly higher mem-
ory using for programs with large ‘if (DEBUG) {...}’ blocks.

SAVEFREEOP was slightly problematic.  Sometimes it can cause an op to
be freed after its CV.  If the CV has forcibly freed the ops on its
slab and the slab itself, then we will be fiddling with a freed slab.
Making SAVEFREEOP a no-op won’t help, as sometimes an op can be
savefreed when there is no compilation error, so the op would never
be freed.  It holds a reference count on the slab, so the whole
slab would leak.  So SAVEFREEOP now sets a special flag on the op
(->op_savefree).  The forced freeing of ops after a compilation error
won’t free any ops thus marked.

Since many pieces of code create tiny subroutines consisting of only
a few ops, and since a huge slab would be quite a bit of baggage for
those to carry around, the first slab is always very small.  To avoid
allocating too many slabs for a single CV, each subsequent slab is
twice the size of the previous.

Smartmatch expects to be able to allocate an op at run time, run it,
and then throw it away.  For that to work the op is simply mallocked
when PL_compcv has’t been set up.  So all slab-allocated ops are
marked as such (->op_slabbed), to distinguish them from mallocked ops.

All of this is kept under lock and key via #ifdef PERL_CORE, as it
should be completely transparent.  If it isn’t transparent, I would
consider that a bug.

I have left the old slab allocator (PL_OP_SLAB_ALLOC) in place, as
it is used by PERL_DEBUG_READONLY_OPS, which I am not about to
rewrite. :-)

Concerning the change from A to X for slab allocation functions:
Many times in the past, A has been used for functions that were
not intended to be public but were used for public macros.  Since
PL_OP_SLAB_ALLOC is rarely used, it didn’t make sense for Perl_Slab_*
to be API functions, since they were rarely actually available.  To
avoid propagating this mistake further, they are now X.

0 files changed, 0 insertions, 0 deletions