| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
distinct from SV. This should fix the CPAN modules that were failing
when the PadnameLVALUE flag was added, because it shared the same
bit as SVs_OBJECT and pad names were going through code paths not
designed to handle pad names.
Unfortunately, it will probably break other CPAN modules, but I think
this change is for the better, as it makes both pad names and SVs sim-
pler and makes pad names take less memory.
|
|
|
|
|
|
| |
Additionally, svp was shadowed.
(clang -Wunreachable-code)
|
|
|
|
|
|
|
|
|
| |
If $x is not referenced or used in lvalue context elsewhere, then the
constant sub can actually share the same scalar as the enclosing sub’s
pad. It doesn’t need to copy. And we don’t in that case, as of
v5.21.5-421-g04472a8. But we need to make sure the PADTMP flag is
turned off at scope exit if the pad has the only reference to the sub.
(The PADTMP flag has been turned on as of v5.21.5-391-g5543332.)
|
|
|
|
|
|
| |
When we capture the lexical variable in order to make sub () {$x}
constant, we don’t have to copy it if it is not modified or referenced
elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No \my$x= yet. Only my $x; \$x =....
It does not work properly with variables closed over from outside;
hence, all the to-do tests fail still, since they do the assign-
ment in evals.
But this much works:
$ ./miniperl -Ilib -Mfeature=:all -e 'my $m; \$m = \$n; warn \$m; warn \$n'
Lvalue references are experimental at -e line 1.
SCALAR(0x7fa04b805510) at -e line 1.
SCALAR(0x7fa04b805510) at -e line 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in PUSH_EXTEND_MORTAL__SV_C, "PL_tmps_ix + 1" would execute
twice, once for the nonmutable if(>=), then again after the potential
tmps_grow call. tmps_grow has an unused return register/void proto, put it
to use by returning ix. Also change tmps_grow to take the result of
"PL_tmps_ix + the constant (usually 1) or non-constant (EXTEND_MORTAL)".
This avoid having to put the constant twice in machine code, once for the
if test, 2nd time for extend length param for tmps_grow call. For
non-constant/EXTEND_MORTAL usage, it allows the C optimizer to have the
length var to go out of liveness sooner if possible. Also the var used for
the if(>=) test is more likely to be in a register than length var.
So "if test variable" is closer on hand to the CPU than length var. In some
cases, if non-const len var isn't used again, it becomes the "ix" variable
by having PL_tmps_ix added to it. Change sv_2mortal to return sv instead
of NULL to remove a unique branch/block of machine code that assigns 0 to
return variable (Visual C didn't figure out return sv == returned NULL,
not sv). See also [perl #121845].
|
|
|
|
|
|
|
|
|
|
|
|
| |
See ff2a62e0c8 for the explanation. The bug fix in that commit did
not apply to foreach’s aliasing.
In short, ($a,$b)=($c,$d) needs to account for whether two of those
variable names could be referring to the same variable.
This commit causes the test suite to exercise a code path in scope.c
added by ff2a62e0c8, which turned out to be buggy. (I forgot to test
it at the time.)
|
|
|
|
| |
SVs_PADMY is now 0, and SvPADMY means !SvPADTMP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PADMY flag was originally used on values stored in pads as a way
to mark those slots ase being in use already during pad allocation.
That changed for the most part all the way back in bbce6d6978
(perl5.003_09), but vestiges still remained, because some ops used
PADMY for their targets. I removed the last one yesterday in
14d91147. So the PADMY flag now serves no purpose.
At run time, the sole purpose of PADMY is to determine the meaning of
the flag bit shared by PADTMP and PADSTALE. If PADMY is set, the flag
means the latter. Instead of that more complicated check, we can just
renumber PADSTALE to use the PADMY bit and assume that anything not
PADTMP is PADMY.
This commit changes the flags and does just enough to get
tests passing (except Peek.t).
fixup for padmy flag renumbering
|
|
|
|
|
|
|
|
|
|
|
| |
$ ./perl -Ilib -e '{ my $x = 3; Internals::SvREADONLY $x, 1; () }'
$ ./perl -Ilib -e '{ my $x = ${qr//}; Internals::SvREADONLY $x, 1; () }'
Modification of a read-only value attempted at -e line 1.
The latter causes $x to be marked FAKE. At the time this code was
introduced in scope.c, read-only+fake meant cow, so the !fake check
was necessary. (That said, it has always behaved incorrectly for glob
copies that are also marked fake.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes bugs related to Hash::Util::unlock accidentally unlocking
internal scalars (e.g., that returned by undef()) and allowing them to
be modified.
Internal read-only values are now marked by two flags, the regular
read-only flag, and the new ‘protected’ flag.
Before this SvREADONLY served two purposes:
1) The code would use it to protect things that must not be modi-
fied, ever (except when the core sees fit to do so).
2) Hash::Util and everybody else would use it to make this unmodifia-
ble temporarily when requested by the user.
Internals::SvREADONLY serves the latter purpose and only flips the
read-only flag, so things that need to stay read-only will remain so,
because of the ‘other’ read-only flag, that CPAN doesn’t know about.
(If you are a CPAN author, do not read this.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ‘no common vars’ optimisation allows perl to copy the values
straight from the rhs to the lhs in a list assignment.
In ($a,$b) = ($c,$d), that means $c gets assigned to $a,
then $d to $b.
If the same variable occurs on both sides of the expression
(($a,$b)=($b,$a)), then it is necessary to make temporary copies of
the variables on the rhs, before assigning them to the left.
If some variables have been aliased to others, then the common vars
detection can be fooled:
*x = *y;
$x = 3;
($x, $z) = (1, $y);
That assigns 1 to $x, and then goes to assign $y to $z, but $y is
the same as $x, which has just been clobbered. So 1 gets assigned
instead of 3.
This commit solves this by recording in each typeglob whether the sca-
lar is an alias of a scalar from elsewhere.
If such a glob is encountered, then the entire expression is ‘tainted’
such that list assignments will assume there might be common vars.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of faking up a GV to pass to the call checker if we have a
lexical sub, just get the GV from CvGV (since that will reify the GV,
even for lexical subs), unless the call checker has not specifically
requested GVs.
For now, we assume the default call checker cannot handle non-GV sub
names, as indeed it cannot. An imminent commit will rectify that.
The code in scope.c was getting the name hek from the proto CV (stowed
in magic on the pad name) if the CV in the pad had lost it. Now, the
proto CV can lose it at compile time via CvGV, so that does not work
anymore. Instead, just get it from the GV.
|
|
|
|
|
| |
This flag will signify that lexical subs should not have package names
associated with them in error messages, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
{
local *MyClass::func = sub {...}; # LINE A
...
} # LINE B
This example caused global method cache reset at both lines A and B
because glob_assign_ref and leave_scope thought that GV's GP refcnt was 2
(because of saving to Save Stack).
Issue has been fixed.
SAVEt_GVSLOT (on leave_scope) now requires refcnt > 2 to reset cache
globally). Additionally, glob_assign_ref when GvINTRO is set temporarily
decrements gp's refcnt by 1. This handles all common cases, however there
are still uncommon use cases when perl still resets cache globally, for
example:
{
local *MyClass::func = sub {...}; # OK
*MyClass::func = sub {...}; # OOPS :(
} # OK
or
{
local *MyClass::func = sub {...}; # OK
{
local *MyClass::func = sub {...}; # OOPS :(
} # OOPS :(
} # OK
* OOPS is a line where global cache reset occurs
* OK - one package cache reset
|
|
|
|
|
|
|
| |
Sub declaration can reuse an existing stub. So it is possible to define
a package sub using a stub that was originally lexical. Hence,
leave_scope needs to take into account that a my-sub may not have a
name hek any more.
|
|
|
|
|
|
|
|
| |
You need to configure with g++ *and* -Accflags=-DPERL_GLOBAL_STRUCT
or -Accflags=-DPERL_GLOBAL_STRUCT_PRIVATE to see any difference.
(g++ does not do the "post-annotation" form of "unused".)
The version code has some of these issues, reported upstream.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PL_markstack_ptr was read once to do the ++ and comparison. Then after
the markstack_grow call, or not, depending on the branch. The code reads
PL_markstack_ptr a 2nd time. It has to be reread in case (or always does)
markstack_grow reallocs the mark stack. markstack_grow has a void retval.
That is a waste of a register. Let us put it to use to return the new
PL_markstack_ptr. In markstack_grow the contents that will be assigned to
PL_markstack_ptr are already in a register. So let the I32* flow out from
markstack_grow to its caller.
In VC2003 32 bit asm, mark_stack_entry is register eax. The retval of
markstack_grow is in eax. So the assignment "=" in
"mark_stack_entry = markstack_grow();" has no overhead. Since the other,
not extend branch, is function call free,
"(mark_stack_entry = ++PL_markstack_ptr)" assigns to eax. Ultimatly with
this patch a 3 byte mov instruction is saved for each instance of PUSHMARK,
and 1 interp var read is removed. I observed 42 callers of markstack_grow
with my disassembler, so theoretically 3*42 bytes of machine code was
removed for me.
Perl_pp_pushmark dropped from 0x2b to 0x28 bytes of x86 VC 2003
machine code. [perl #122034]
|
|
|
|
|
|
|
|
| |
I've gone through pp_hot.c and scope.c and added LIKELY() or UNLIKELY()
to all conditionals where I understand the code well enough to know that
a particular branch is or isn't likely to be taken very often.
I also processed some of the .h files which contain commonly used macros.
|
|
|
|
|
|
| |
The macros assert_not_ROK(sv) and assert_not_glob(sv) are intended to be used
in expressions, and finish with a trailing comma, so they shouldn't have a ;
after them.
|
|
|
|
|
|
|
|
| |
Currently it takes the 'clear-in-place' branch on lexical vars if
the ref count is <= 1. However, RC < 1 is a "should never happen"
condition, so rather than keeping that damaged var, take the other branch,
which will call SvREFCNT_dec() on it, which will Do the Right Thing
(like emitting a warning).
|
|
|
|
|
|
| |
Add SVf_OOK to the list of flags that are handled in the 'slow' branch.
This allows us to avoid checking for hv_kill_backrefs() or sv_backoff()
for the majority of lexicals which won't require it.
|
|
|
|
| |
the next commit will change thinks that affect only part of the macro
|
|
|
|
|
|
|
|
|
|
|
| |
SAVEt_CLEARSV should always be called with SvPADMY() true, so don't test
for it, but assert it instead. Then change this:
if (SvPADMY(sv) && !SvFAKE(sv))
SvREADONLY_off(sv);
The SvPADMY() isn't needed, but we should test for RO-ness instead, to
avoid an unnecessary SvREADONLY_off().
|
|
|
|
| |
whitespace-only changes
|
|
|
|
|
|
|
|
| |
In the 'clear' branch of SAVEt_CLEARSV, there are several individual
if (SvSOMEFLAG(sv)) {...} tests. Wrap all these tests in a single
if (SvFLAGS(sv) & (union|of|all|flags)), so that for the common case
of boring lexicals that don't need special clear up, we can skip all the
individual tests
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of ticket #119295.
Commit 7fa949d (5.19.3) allowed copy-on-write with compile-time con-
stants. That caused this to fail:
use Variable::OnDestruct:
{
my $h = "foo";
on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" };
$x++; # prev statement must not be last in the block
}
It prints undef instead of foo.
It turns out this is much older:
use Variable::OnDestruct;
{
my $h = __PACKAGE__;
on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" };
$x++; # prev statement must not be last in the block
}
This one prints undef starting with 5.17.3 (a6d7a4ac1).
But even before that, this prints undef:
use Variable::OnDestruct;
{
my $h = \1;
on_destruct $h, sub { warn defined $_[0] ? $_[0] : "undef" };
$x++; # prev statement must not be last in the block
}
In all these cases, the scalar is getting undefined before free magic
triggers (Variable::OnDestruct uses free magic).
Usually when a scalar is freed, the magic is triggered before anything
else. When a lexical scalar is ‘freed’ on scope exit (cleared for
reuse on scope entry), the order is different. References, globs and
copy-on-write scalars become undefined (via sv_force_normal) before
magic is triggered.
There is no reason for the order to be different here, and it causes
unpredictable behaviour (you never know when you will or will not have
a cow). So change the order in scope exit to match regular freeing.
|
|
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(I am referring to what is usually known simply as The Stack.)
This partially fixes #119161.
By casting the argument to int, we can end up truncating/wrapping
it on 64-bit systems, so EXTEND(SP, 2147483648) translates into
EXTEND(SP, -1), which does not extend the stack at all. Then writing
to the stack in code like ()=1..1000000000000 goes past the end of
allocated memory and crashes.
I can’t really write a test for this, since instead of crashing it
will use more memory than I have available (and then I’ll start for-
getting things).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial fix for #119161.
On 64-bit platforms, I32 is too small to hold offsets into a stack
that can grow larger than I32_MAX. What happens is the offsets can
wrap so we end up referencing and modifying elements with negative
indices, corrupting memory, and causing crashes.
With this commit, ()=1..1000000000000 stops crashing immediately.
Instead, it gobbles up all your memory first, and then, if your com-
puter still survives, crashes. The second crash happesn bcause of
a similar bug with the argument stack, which the next commit will
take care of.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c82ecf346.
It turn out to be faulty, because a location shared betweens threads
(the cop) was holding a reference count on a pad entry in a particu-
lar thread. So when you free the cop, how do you know where to do
SvREFCNT_dec?
In reverting c82ecf346, this commit still preserves the bug fix from
1311cfc0a7b, but shifts it around.
|
|
|
|
| |
81ed78b25c4b removed the only use of this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves having to allocate a separate string buffer for every cop
(control op; every statement has one).
Under non-threaded builds, every cop has a pointer to the GV for that
source file, namely *{"_<filename"}.
Under threaded builds, the name of the GV used to be stored instead.
Now we store an offset into the per-interpreter PL_filegvpad, which
points to the GV.
This makes no significant speed difference, but it reduces mem-
ory usage.
|
|
|
|
|
|
|
|
|
| |
$ ./perl -Ilib -e '@a=1..2; eval { @a=sort{die} @a }; warn "ok so far\n"; @a = 1'
ok so far
Modification of a read-only value attempted at -e line 1.
If something goes wrong inside the sort block and it dies, we still
need to make sure we turn off the read-only flag on that array.
|
|
|
|
|
|
|
|
|
|
| |
This is a struct that holds all the global state of the current regex
match.
The previous set of commits have gradually removed all the fields of this
struct (by making things local rather than global state). Since the struct
is now empty, the PL_reg_state var can be removed, along with the
SAVEt_RE_STATE save type which was used to save and restore those fields
on recursive re-entry to the regex engine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate these two global vars (well, fields in the global
PL_reg_state), that hold the regex super-liner cache.
PL_reg_poscache_size gets replaced with a field in the local regmatch_info
struct, while PL_reg_poscache (which needs freeing at end of pattern
execution or on croak()), goes in the regmatch_info_aux struct.
Note that this includes a slight change in behaviour.
Each regex execution now has its own private poscache pointer, initially
null. If the super-linear behaviour is detected, the cache is malloced,
used for the duration of the pattern match, then freed.
The former behaviour allocated a global poscache on first use, which was
retained between regex executions. Since the poscache could between 0.25
and 2x the size of the string being matched, that could potentially be a
big buffer lying around unused. So we save memory at the expense of a new
malloc/free for every regex that triggers super-linear behaviour.
The old behaviour saved the old pointer on reentrancy, then restored the
old one (and possibly freed the new buffer) at exit. Except it didn't for
(?{}), so /(?{ m{something-that-triggers-super-linear-cache} })/ would
leak each time the inner regex was called. This is now fixed
automatically.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PERL_ASYNC_CHECK() was added to Perl_leave_scope() as part of commit
f410a2119920dd04, which moved signal dispatch from the runloop to
control flow ops, to mitigate nearly all of the speed cost of safe
signals.
The assumption was that scope exit was a safe place to dispatch signals.
However, this is not true, as parts of the regex engine call
leave_scope(), the regex engine stores some state in per-interpreter
variables, and code called within signal handlers can change these
values.
Hence remove the call to PERL_ASYNC_CHECK() from Perl_leave_scope(), and
add it explicitly in the various OPs which were relying on their call to
leave_scope() to dispatch any pending signals. Also add a
PERL_ASYNC_CHECK() to the exit of the runloop, which ensures signals
still dispatch from S_sortcv() and S_sortcv_stacked(), as well as
addressing one of the concerns in the commit message of
f410a2119920dd04:
Subtle bugs might remain - there might be constructions that enter
the runloop (where signals used to be dispatched) but don't contain
any PERL_ASYNC_CHECK() calls themselves.
Finally, move the PERL_ASYNC_CHECK(); added by that commit to pp_goto to
the end of the function, to be consistent with the positioning of all
other PERL_ASYNC_CHECK() calls - at the beginning or end of OP
functions, hence just before the return to or just after the call from
the runloop, and hence effectively at the same point as the previous
location of PERL_ASYNC_CHECK() in the runloop.
|
|
|
|
|
| |
The are lots of places where local vars aren't used when compiled
with NO_TAINT_SUPPORT.
|
|
|
|
|
|
|
| |
Clang under Address sanitizer is showing several problems when building
Perl, having to do when a limit reaches I32_MAX. This commit fixes
those problems by doing special tests for I32_MAX, and preventing
overflow.
|
|
|
|
| |
clang didn't like %ld on I32's.
|
|
|
|
|
|
|
|
|
| |
Like SvREFCNT_dec(), but skips the not null check, making code potentially
smaller and faster.
Also as proof of concept, updates the SvREFCNT_dec's in scope.c where
it's obvious the value can't be NULL. There are still 500+ uses in the
perl core that need evaluating!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several places that have code similar to
if (SvMAGICAL(sv)) {
PL_localizing = 2;
SvSETMAGIC(sv)
PL_localizing = 0;
}
The condition is sub-optimal (it should only test for set magic), and the
SvSETMAGIC repeats a similar test.
Other places didn't have the outer condition, so they set PL_localizing
twice even when not needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large and hot function. The main problem with it is that
there is code to pop a few args repeated in just about every branch.
Also, there are a whole bunch of local vars (sv, av, hv, gv etc)
that are never all used simultaneously, but are really just there for
casting convenience. Together, they defeat the compiler's register
allocation algorithms (well, they did for gcc anyway).
We fix this by just declaring three general vars, arg0,1,2 of type ANY, and
move the popping code to above the switch(). We sort the SAVEt_*
indices in order of number of args, so it's quick to determine how many
args we need to pop for a particular type.
Together with the previous commits which added the SS_ADD_* macros, this
reduces the size of scope.o (-O2, gcc x86_64) by about 9% (threaded)
or 17% (unthreaded), and seems to speed up simple loops / function calls
by around 5%.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both these functions were structured as
if (int will fit in type)
SS_ADD(...);
else
save_pushi32ptr(...)
Inline the call of the "long" version of the save. With refactoring, the
machine code (x86_64, gcc -O2) is no larger than before, and saves time
on the long version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current idiom for adding an entry to the savestack is
SSCHECK(3);
SSPUSHINT(...);
SSPUSHPTR(...);
SSPUSHUV(SAVEt_...);
Replace this with a new idiom:
{
dSS_ADD;
SS_ADD_INT(...);
SS_ADD_PTR(...);
SS_ADD_UV(SAVEt_...);
SS_ADD_END(3);
}
This is designed to be more efficient.
First, it defines some local vars, and defers updating PL_savestack_ix
to the end.
Second, it performs the 'is there space on the stack' check *after*
pushing. Doing the check last means that values in registers will have
been pushed and no longer needed, so don't need saving around the call to
grow. Also, tail-call elimination of the grow() can be done. These changes
reduce the code of something like save_pushptrptr() to half its former
size.
Of course, doing the size check *after* pushing means we must always
ensure there are SS_MAXPUSH free slots on the savestack */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
local *foo=sub{} is done in two stages:
• First the local *foo localises the GP (the glob pointer, or list of
slots), setting a flag on the GV.
• Then scalar assignment sees the flag on the GV on the LHS and loca-
lises a single slot.
The slot localisation only stores on the savestack a pointer into the
GP struct and the old value. There is no reference to the GV.
To restore a method properly, we have to have a reference to the GV
when the slot localisation is undone.
So in this commit I have added a new save type, SAVEt_GVSLOT. It is
like SAVEt_GENERIC_SV, except it pushes the GV as well. Currently
it is used only for CVs, but I will need it for HVs and maybe
AVs as well.
It is possible for the unwinding of the slot localisation to affect
only a GV other than the one that is pushed, if glob assignments have
taken place since the local *foo. So we have to check whether the
pointer is inside the GP and use PL_sub_generation++ if it is not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was already working for those cases where *foo contained a sub
before and after localisation. For those cases where *foo had no sub
but localised assignment gave it one, method caches were not being
reset on scope exit.
case SAVEt_GP in scope.c:leave_scope needs to look at both GPs (glob
pointer, or list of glob slots), both from before and after the unlo-
calisation. If either has a sub, method caches need to be cleared.
This does not yet fix local *foo = sub {}, but I added a to-do
test for it. (This is more complicated, as localisation happens in
two seperate steps, the glob slot localisation storing no pointers to
the glob itself on the savestack.)
|
|
|
|
|
|
|
|
|
|
| |
These are regressions from 5.8.
local *ISA was not updating isa caches. local *ISA = [] was updating
caches, but scope unwinding was not.
Both save_gp and leave_scope/SAVEt_GP need to check whether the glob
is named ISA and call mro_isa_changed_in if appropriate.
|
|
|
|
|
|
|
| |
save_gp was trying to call mro_method_changed_in even if the stash had
been detached.
This is a regression from 5.12.
|