Branch: refs/heads/yves/cop_file_rcpv
Home: https://github.com/Perl/perl5
Commit: 0deb3928e9a771dea3b1c685294cbd054e1d1e2c
https://github.com/Perl/perl5/commit/0deb3928e9a771dea3b1c685294cbd054e1d1e2c
Author: Yves Orton <demer...@gmail.com>
Date: 2022-10-30 (Sun, 30 Oct 2022)
Changed paths:
M dump.c
Log Message:
-----------
dump.c - add missing cast
In 06d92f00e810ad2f12b8fb9c1adf0d22765d6ccc we added the CV_FROM_REF()
macros, these macros assume the argument is an SV, so the gv prequires
a cast. The argument was cast to SV* in another case, so I am adding the
same fix here.
Silences the following warning:
dump.c: In function ‘S_gv_display’:
dump.c:880:58: warning: initialization of ‘SV *’ {aka ‘struct sv *’} from
incompatible pointer type ‘GV *’ {aka ‘struct gv *’}
[-Wincompatible-pointer-types]
880 | SvPV_nolen_const(cv_name(CV_FROM_REF(gv), name,
0)));
| ^~
sv.h:1912:42: note: in definition of macro ‘SvPV_flags_const_nolen’
1912 | ((const char*) Perl_SvPV_helper(aTHX_ sv, NULL, flags,
SvPVnormal_type_, \
| ^~
dump.c:880:21: note: in expansion of macro ‘SvPV_nolen_const’
880 | SvPV_nolen_const(cv_name(CV_FROM_REF(gv), name,
0)));
| ^~~~~~~~~~~~~~~~
dump.c:880:38: note: in expansion of macro ‘cv_name’
880 | SvPV_nolen_const(cv_name(CV_FROM_REF(gv), name,
0)));
| ^~~~~~~
handy.h:136:27: note: in expansion of macro ‘xV_FROM_REF’
136 | #define CV_FROM_REF(ref) xV_FROM_REF(CV, ref)
| ^~~~~~~~~~~
dump.c:880:46: note: in expansion of macro ‘CV_FROM_REF’
880 | SvPV_nolen_const(cv_name(CV_FROM_REF(gv), name,
0)));
Commit: 0907345d47afc7ad36e17c2fd9aa0c950824235c
https://github.com/Perl/perl5/commit/0907345d47afc7ad36e17c2fd9aa0c950824235c
Author: Yves Orton <demer...@gmail.com>
Date: 2022-10-30 (Sun, 30 Oct 2022)
Changed paths:
M cop.h
M embed.fnc
M embed.h
M ext/B/B.pm
M ext/B/B.xs
M gv.c
M op.c
M op.h
M perl.c
M proto.h
M scope.c
M scope.h
M sv.c
Log Message:
-----------
cop.h - add support for refcounted filenames in cops under threads
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 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.
Compare: https://github.com/Perl/perl5/compare/0deb3928e9a7%5E...0907345d47af
