When a `my` SV goes out of scope, any OOK hack on its string buffer is
undone by `Perl_sv_backoff`. If the SV is `SvOK`, a copy of the buffer
contents will occur, but since the contents are defunct at this point,
the copy is unnecessary.
See https://github.com/Perl/perl5/issues/23967 as an example of where
this unnecessary copy had a noticeable effect on performance.
This commit essentially inlines the necessary parts of `sv_backoff` to
avoid the copy, without excessive messing around with `sv`'s flags at
the call site in `Perl_leave_scope`.
Previous on Win32 this could cause a double-free of the RExC state if
an emulated fork was done with the free of the state on the scope
stack.
Use a custom save type and prevent freeing in the cloned process to
prevent the double-free.
Fixes#23022
This allows a debugging perl to be built with the high water mark
checks disabled, or a non-debugging perl to be built with the
high water marks enabled.
This should allow Debian, the reporter for #16607 to build both their
normal perl and debugperl with the same state of high water mark
checks and avoid the mismatch between a debugperl and non-debug
dynamic extension.
Fixes#16607
As with the value stack and the save stack, this gives us constant
amortized growth per element.
After this patch the profiler shows the "SvPV_shrink_to_cur(sv)"
and "sv = sv_2mortal(newSV(80))" calls in do_readline as the
hotspots for the io unheated test case, using 55% of the measured
time in total.
Fixes#21654
By default it will use I32 for backward compatibility, but you
can select SSize_t during configuration with:
-Accflags=-DPERL_STACK_OFFSET_SSIZET
which may one day become the default.
The actual offsets throughout the code continue to be SSize_t.
When built with PERL_RC_STACK, this substantial commit:
* makes stacks AvREAL() by default.
* adds the si_stack_nonrc_base field to the stackinfo structure.
* adds the runops_wrap() wrapper
It also adds rpp_obliterate_stack_to() for clearing the stack on
exceptions
Collectively, this allows each stack to be in one of three states:
1) AvREAL(PL_curstack) && PL_curstackinfo->si_stack_nonrc_base == 0
(the new default) all the SVs pointed to from the stack are
reference-counted.
2) AvREAL(PL_curstack) && PL_curstackinfo->si_stack_nonrc_base > 0
items on the stack are reference-counted only below si_stack_nonrc_base.
3) !AvREAL(PL_curstack)
(existing behaviour) no items on the stack are reference-counted.
The way it generally works is that runops loops assume that all the PP
functions they call out to are reference-count-aware. Where this isn't
yet the case, the recently-added pp_wrap() and xs_wrap() functions
assume a reference-counted stack, but use the si_stack_nonrc_base
mechanism to call out to PP or XS functions which aren't aware of a
reference-counted stack.
Conversely, the runops_wrap() function added by this commit wraps calls
to runops loops, since such loops work only with an RC stack. So if
called with a non-RC or partially-RC stack, the wrapper temporarily
fixes up the stack to be fully-RC, calls the real runops loop, then on
return reverts the stack back to it's non-RC ways, mortalising any
return values if necessary.
This downgrading and upgrading by pp_wrap()/xs_wrap() and
runops_wrap() allows handling of multiple nesting of when, for
example, perl calls pp_entersub(), which calls XS code, which calls
call_sv(), which calls a runops loop, which calls pp_entersub(), which
calls XS code, and so on.
For si_stack_nonrc_base, this index value marks the lowest position on
the argument stack which is not reference-counted. The special (and
normal) value of 0 indicates that *all* items on the stack are
reference-counted.
The new function rpp_obliterate_stack_to() is a bit like
rpp_popfree_to(), except that it can handle stacks in all three of the
states listed above. It's intended to be used when dying, throwing
exceptions or exiting, since the stack could be in any state when that
happens.
Note that as of this commit, PERL_XXX_TMP_NORC is still defined, which
means that even in the presence of AvREAL(PL_curstack) etc, the stack
isn't yet actually reference counted. So with this commit, perl goes
through all the motions, (calling wrappers like runops_wrap()
etc), but skips actually manipulating any reference counts. There will
be a few more commits, fixing up a few more things, before
PERL_XXX_TMP_NORC will be removed.
Add a _flags() variant of new_stackinfo() which indicates whether the
new stack AV should be created real or not.
Modify the new push_stackinfo() function to have a similar flag.
Then make the backcompat macros like PUSHSTACKi() still push a non-real
stack, while functions which have been updated to use the new
push_stackinfo() etc will be able get a real AV. The next commit makes
use of that.
This means that existing code (core and XS) which hasn't been updated to
the new ref-counted stack regime can do stuff like:
PUSHSTACKi(FOO);
PUSHMARK(sp)
XPUSHs(sv);
call_sv();
where call_sv() (or rather, the runops loop it invokes) will be able to
determine that it's been called from a non-RC environment and that the
args on the stack aren't reference-counted.
The next commit will update the runops loops etc to do exactly that.
On PERL_RC_STACK builds, skip the call to SAVESTACK_POS().
I suspect that saving the stack position is no longer
required. It was added in 5.001 by:
NETaa13155: &DB::DB left trash on the stack.
From: Thomas Koenig
Files patched: lib/perl5db.pl pp_ctl.c
The call by pp_dbstate() to &DB::DB left trash on the
stack. It now calls DB in list context, and DB returns
().
but the details of what bug it fixed are long lost to history.
SAVESTACK_POS() doesn't work well with stacks which may be split into
partly reference-counted and partly not halves, so skip it and hope it
doesn't cause any problems.
Also, assert that SAVEt_STACK_POS isn't used anywhere any more.
The function SAVEDESTRUCTOR_X() (save_destructor_x) can be used to
execute a C function at the end of the current psuedo-block. Prior to
this patch there was no "mortal" equivalent that would execute at the
end of the current statement. We offer a collection of functions which
are intended to free SV's at either point in time, but only support
callbacks at the end of the current pseudo-block.
This patch adds two such functions, "mortal_destructor_sv" which can be
used to trigger a perl code reference to execute at the end of the
current statement, and "mortal_svfunc_x" which can be used to trigger an
SVFUNC_t C function at the end of the current statement.
Both functions differ from save_destructor_x() in that instead of
supporting a void pointer argument they both require their argument to
be some sort of SV pointer. The Perl callback function triggered by
"mortal_destructor_sv" may be provided no arguments, a single argument
or a list of arguments, depending on the type of argument provided to
mortal_destructor_sv(): when the argument is a raw AV (with no SV ref
wrapping it), then the contents of the AV are passed in as a list of
arguments. When the argument is anything else but NULL, the argument is
provided as a single argument, and when it is NULL the perl function is
called with no arguments.
Both functions are implemented on top of a mortal SV (unseen by the
user) which has PERL_MAGIC_destruct magic associated with it, which
triggers the destructor behavior when the SV is freed.
Both functions are provided with macros to match the normal SAVExx()
API, with MORTALDESTRUCTOR_SV() wrapping mortal_destructor_sv() and
MORTALSVFUNC_X() wrapping mortal_svfunc_x().
The heart of this logic cribbed from Leon Timmermans' Variable-OnDestruct.
See the code at:
https://metacpan.org/dist/Variable-OnDestruct/source/lib/Variable/OnDestruct.xs#L6-17
I am very grateful to him for his help on this. Any errors or omissions
in this code are my fault, not his.
I misnamed some of the RCPV stuff when it was introduced. The macro
which I called SAVERCPVFREE should have been called SAVERCPV,
and there should also have been a SAVEFREERCPV macro.
Note the naming system for these functions is a bit confusing.
SAVEFREERCPV /just/ frees. SAVERCPV saves and restores (eg, its like
local). SAVEFREESV is an exception. :-( and it behaves like SAVERCPV.
See for instance SAVEPV or similar macros.
There also should have been RCPV_REFCNT_dec() and RCPV_REFCNT_inc()
macros.
There was also missing documentation. This patch should fix all of these
issues. Since this functionality has never been released in a production
perl it should be fine to do these renames, nothing out there should use
these macros yet.
I noticed these oversights while fixing Scope::Upper, see also:
https://github.com/Perl/perl5/issues/20861https://rt.cpan.org/Ticket/Display.html?id=146897
Prior to this patch SSCHECK() took a "needs" parameter, but did not
actually guarantee that the stack would be sufficiently large to
accomodate that many elements after the call. This was quite misleading.
Especially as SSGROW() would not do geometric preallocation, but
SSCHECK() would, so much of the time SSCHECK() would appear to be a
better choice, but not always.
This patch makes it so SSCHECK() is an alias for SSGROW(), and it makes
it so that SSGROW() also geometrically overallocates. The underlying
function that used to implement SSCHECK() savestack_grow() now calls the
savestack_grow_cnt() which has always implemented SSGROW(). Anything
in the internals that used to call SSCHECK() now calls SSGROW() instead.
At the same time the preallocation has been made a little bit more
aggressive, ensuring that we always allocate at least SS_MAXPUSH
elements on top of what was requested as part of the "known" size of the
stack, and additional SS_MAXPUSH elements which are not part of the
"known" size of the stack. This "hidden extra" is used to simply some of
the other macros which are used a lot internally. (I have beefed up the
comment explaining this as well.)
This fixes GH Issue #20826
gcc 12 was complaining that evaluating (somehekptr)->hek_key
was always true in many places where HvNAME() or HvENAME() was
being called in boolean context.
Add new macros to check whether the names should be available and
use those instead.
We can't put PL_compiling or PL_curcop on the save stack as we don't
have a way to ensure they cross threads properly. This showed up as a
win32 t/op/fork.t failure in the thread based fork emulation layer.
This adds a new save type SAVEt_CURCOP_WARNINGS and macro
SAVECURCOPWARNINGS() to complement SAVEt_COMPILER_WARNINGS and
SAVECOMPILEWARNINGS(). By simply hard coding where the pointers should
be restored to we side step the issue of which thread we are in.
Thanks to Graham Knop for help identifying that one of my commits was
responsible.
The normal savestack index is an I32, but that counts in ANY
(which are typically the larger of pointer or IV sizes), this
meant is the save stack was large, but still nowhere need it's
limit, the result of SSNEW() could overflow.
So make the result SSize_t and adjust SSPTR() to match.
SSPTR() asserts to ensure the supplied type is the same size as
SSize_t to ensure callers are updated to handle the new limit.
We have a weird bifurcation of the cop logic around threads. With
threads we use a char * cop_file member, without it we use a GV * and
replace cop_file with cop_filegv.
The GV * code refcounts filenames and more or less efficiently shares
the filename amongst many opcodes. However under threads we were
simplify copying the filenames into each opcode. This is because in
theory opcodes created in one thread can be destroyed in another. I say
in theory because as far as I know the core code does not actually do
this. But we have tests that you can construct a perl, clone it, and
then destroy the original, and have the copy work just fine, this means
that opcodes constructed in the main thread will be destroyed in the
cloned thread. This in turn means that you can't put SV derived
structures into the op-tree under threads. Which is why we can not use
the GV * stategy under threads.
As such this code adds a new struct/type RCPV, which is a refcounted
string using shared memory. This is implemented in such a way that code
that previously used a char * can continue to do so, as the refcounting
data is located a specific offset before the char * pointer itself.
This also allows the len data to embedded "into" the PV, which allows
us to expose macros to acces the length of what is in theory a null
terminated string.
struct rcpv {
UV refcount;
STRLEN len;
char pv[1];
};
typedef struct rcpv RCPV;
The struct is sized appropriately on creation in rcpv_new() so that the
pv member contains the full string plus a null byte. It then returns a
pointer to the pv member of the struct. Thus the refcount and length and
embedded at a predictable offset in front of the char *, which means we
do not have to change any types for members using this.
We provide three operations: rcpv_new(), rcpv_copy() and rcpv_free(),
which roughly correspond with newSVpv(), SvREFCNT_inc(), SvREFCNT_dec(),
and a handful of macros as well. We also expose SAVERCPVFREE which is
similar to SAVEGENERICSV but operates on pv's constructed with
rcpv_new().
Currently I have not restricted use of this logic to threaded perls. We
simply do not use it in unthreaded perls, but I see no reason we
couldn't normalize the code to use this in both cases, except possibly
that actually the GV case is more efficient.
Note that rcpv_new() does NOT use a hash table to dedup strings. Two
calls to rcpv_new() with the same arguments will produce two distinct
pointers with their own refcount data.
Refcounting the cop_file data was Tony Cook's idea.
Various code related to set_and_free_cop_warnings was terribly mangled
as far as whitespace goes. This patch cleans it up so it is readable and
correctly indented. Whitespace only changes.
I believe the '!!' is somewhat obscure; I for one didn't know about it
for years of programming C, and it was buggy in one compiler, which is why
cBOOL was created, I believe. And it is graphically dense, and
generally harder to read than the cBOOL() construct.
This commit dates from before we moved to C99 where we can simply cast
to (bool), and cBOOL() has been rewritten to do that. But the vast
majority of code uses cBOOL(), and this commit brings the remainder of
the core .[ch] files into uniformity.
When a function outside of sv.c creates a SV via newSV(0):
* There is a call to Perl_newSV
* A SV head is uprooted and its flags set
* A runtime check is made to effectively see if 0 > 0
* The new SV* is returned
Replacing newSV(0) with newSV_type(SVt_NULL) should be more efficient,
because (assuming there are SV heads to uproot), the only step is:
* A SV head is uprooted and its flags set
Adds syntax `defer { BLOCK }` to create a deferred block; code that is
deferred until the scope exits. This syntax is guarded by
use feature 'defer';
Adds a new opcode, `OP_PUSHDEFER`, which is a LOGOP whose `op_other` field
gives the start of an optree to be deferred until scope exit. That op
pointer will be stored on the save stack and invoked as part of scope
unwind.
Included is support for `B::Deparse` to deparse the optree back into
syntax.
This just detabifies to get rid of the mixed tab/space indentation.
Applying consistent indentation and dealing with other tabs are another issue.
Done with `expand -i`.
* vutil.* left alone, it's part of version.
* Left regen managed files alone for now.
Most uses of SAVEt_STRLEN actually store small values; often zero.
Rather than using an entire U64-sized element for these values, it saves
space to use the same "SMALL" mechanism as other numerical values, like
SAVEt_INT_SMALL.
This feature allows documentation destined for perlapi or perlintern to
be split into sections of related functions, no matter where the
documentation source is. Prior to this commit the line had to contain
the exact text of the title of the section. Now it can be a $variable
name that autodoc.pl expands to the title. It still has to be an exact
match for the variable in autodoc, but now, the expanded text can be
changed in autodoc alone, without other files needing to be updated at
the same time.
Rather than possibly push an extra HV* to the save stack if the right
bit is set in the (saved) hints flags, better just to define a different
SAVEt type. Having done this, the stack layout is now constant per type
value.
This fixes
https://github.com/Perl/perl5/issues/17895
