pad.c:pad_reset: check the name

This code was sufficiently out-of-date to trip assertions in miniperl,
breaking the build (with -Accflags=-DUSE_BROKEN_PAD_RESET).

We can’t SvPADTMP_off on just anything, because it asserts that the
thing is !SvPADMY.

So check that it has no name first.  A pad entry without a name is an
operator target (or an unallocated entry).

The build is still broken, but it gets a bit further.
pad.c:pad_reset: Also make sure the thing is not PADMY

We can’t SvPADTMP_off on just anything, because it asserts that the
thing is !SvPADMY.

A range operator has a target of sorts, but that target must not be
shared with any other operators; hence it gets allocated like a
‘my’ variable.  The target thus ends up with the SvPADMY flag set.  We
obviously don’t want to mark those targets as reusable in pad_reset,
so just skip them.

This gets things mostly working under USE_BROKEN_PAD_RESET without
threads, but a few tests still fail.
pad.c: More clearly separate targ/constant allocation

pad_reset was turning off PADTMP on targets to make them ‘available’
again.  But constants allocated later could then end up using those
slots.  We can’t share pad slots between constants and targets,
because operators allocated earlier will trigger ‘Modification of
a read-only value’ errors when trying to assign return values to
their targets.

Under non-threaded builds, in which constants are not generally stored
in the pad, there are still ‘constants’ that are allocated as such
(with &PL_sv_no names) but are not actually read-only.  Filehandle
names associated with ‘open my $fh’ are one such example.  If that
filehandle name’s pad slot is shared with a target, then the file-
handle will be named using some random string from a previous
statement.

The solution here is to change the way we use the PADTMP flag when
allocating pad slots.  pad_reset should *not* turn off the flag,
because we need to know that these entries are used as targets by pre-
vious statements.  pad_alloc should not tread PADTMP entries as being
in use when allocating targets, but only when allocating constants.

This gets all tests passing under -Accflags=-DUSE_BROKEN_PAD_RESET
on non-threaded builds.
op.c:ck_rvconst: Allocate GV pad slots like constants

Requesting a pad slot for a constant (and GVs in pads are like con-
stants, in that the pad slot will always hold that same value, which
is shared in recursion) will instruct pad_alloc to avoid anything
marked PADTMP; i.e., a  slot used as a target by a previous statement.

Without this, we get an assertion failure from ‘miniperl -MExporter’
under -Accflags=-DUSE_BROKEN_PAD_RESET and threads.

With this commit, we get ‘Modification of a read-only value attempted’
instead, which is some progress. :-)
pad.c:pad_free: Don’t turn off the PADTMP flag

When we mark a pad entry as being free, it may happen (under
USE_BROKEN_PAD_RESET) that multiple operators from different state-
ments are using the same pad entry for their targets.  If we turn off
the PADTMP flag, the slot may be reused for a constant.  Then an oper-
ator that tries to return a value by assigning to its target will try
to modify a read-only scalar.

Now that (as of a few commits ago) allocation of targets (in
pad_alloc) will reuse entries marked PADTMP, turning off the flag is
not necessary to make a slot available.

This gets the build for USE_BROKEN_PAD_RESET+threads a little further.
The Exporter test now passes, but configpm trips an assertion....
op.c:newPADOP: Allocate GV pad slots like constants

Requesting a pad slot for a constant (and GVs in pads are like con-
stants, in that the pad slot will always hold that same value, which
is shared in recursion) will instruct pad_alloc to avoid anything
marked PADTMP; i.e., a  slot used as a target by a previous statement.

Without this, under -Accflags=-DUSE_BROKEN_PAD_RESET and threads,
configpm fails an assertion, because a concat operator tries to do
sv_grow on its target, but that target has ended up becoming a GV.

With this commit, all tests pass, but t/re/uniprops.t takes ‘forever’
(cf. commits 325e1816 and 7db6405c, which caused and fixed, respec-
tively, a similar bug).
uniprops.t: Correct command line in comment
intrpvar.h: Correct comment

This description has been a little faulty for quite some time, not
just because of the last few commits.  Any time pad_free or pad_swipe
is called, that pad slot becomes available and PL_padix is reset.
So ‘max used’ is not accurate.
Split PL_padix into two variables

PL_padix keeps track of the position in the pad when pad_alloc has to
start scanning for an available slot.

The availability of a slot is determined differently for targets
(which may reuse slots that are already targets from previous state-
ments, at least when pad_reset is enabled) and constants (which may
not reuse targets).

Having the same index for both may require scanning the entire pad for
allocating a constant or GV.

t/re/uniprops.t was running far too slowly under USE_BROKEN_PAD_RESET
because of this.  pad_reset would reset PL_padix to point to the
beginning of a pad with a few hundred thousand entries.  pad_alloc
would then have to scan the entire pad before adding a GV to the end.

It is still too slow, even with this commit, but for other reasons.
(This is just a partial fix.)
pad.c: Use PadnamelistMAXNAMED in another place

This will speed up pad lookup a little more.  This could be considered
a follow-up to commit 7db6405c.

There is a hack that allows an ‘our’ variable to be found in the pad
in the statement in which it is declared, to avoid a warning (since
the fallback would be to look up the very same variable in the current
package anyway).

This commit applies the PadnamelistMAXNAMED optimisation to that code
path.  This is how that optimisation works:  When named slots are
allocated in the pad, PadnamelistMAXNAMED is set, so that, when
searching for named items in the pad, we don’t have to search the
whole thing if there are many constants or GVs at the end.

Recent commits slowed down t/re/uniprops.t considerably.  This was the remaining bottleneck.

We could actually skip the whole ‘our’ hack for subroutine lookup
(since the warning it avoids doesn’t apply to subroutines anyway).  In
fact, the next commit will do that.  But this optimisation is worth-
while anyway.
pad.c:pad_findmy_pvn: Skip ‘our’ hack for subs

There is a hack that allows an ‘our’ variable to be found in the pad
in the statement in which it is declared, to avoid a warning (since
the fallback would be to look up the very same variable in the current
package anyway).

Since the warning this hack avoids doesn’t apply to subroutines, we
can just skip it for subroutine lookup.
pad.c:pad_free: Don’t reset PL_padix if using pad_reset

pad_reset causes PL_padix to be reset at the beginning of each state-
ment, so that operator targets can be reused.

If we also reset it when freeing an operator, then theoretically tar-
gets from operators later on in the same statement might be reused.  I
can’t come up with a test case, but it’s better to be safe than sorry.
pad.c: Remove BROKEN from USE_BROKEN_PAD_RESET
Fix up Peek.t
pad.c: pad_reset comments
Make Peek.t easier to run directly

e.g., ./perl -TIlib ext/Devel-Peek/t/Peek.t
[Merge] pad_reset

This branch gets builds with pad_reset enabled working and changes the

For those who do not know what pad_reset does, pad_reset allows oper-
ators from different statements to share targets, saving memory.  When
it was originally added, it never fully worked properly, so it was
disabled, since it caused bugs.

For those who do not know what operator targets are:  Many operators
use the same scalar every time they return a value, to avoid having to
create a new one each time.  This is known as the target.

To keep t/re/uniprops.t running in a reasonable amount of time (unfor-
tunate coincidences slowed it down signficantly), I had to add two
optimisations.  See the commits entitled:

    Split PL_padix into two variables
    pad.c: Use PadnamelistMAXNAMED in another place

These optimisations apply even when pad_reset is disabled.

Benchmarking doesn’t show any speedup with pad_reset
enabled, so I left it disabled for now.  See
<20140828045810.19174.qmail@lists-nntp.develooper.com> for benchmark-
ing details.

(I am hoping that I can figure out why it’s slower and enable it some
future date.)