In perl.git, the branch davem/cow3 has been created
<http://perl5.git.perl.org/perl.git/commitdiff/fd41e6e9dfd302c7274e6f3bee6e5cc10dcb7b0a?hp=0000000000000000000000000000000000000000>
at fd41e6e9dfd302c7274e6f3bee6e5cc10dcb7b0a (commit)
- Log -----------------------------------------------------------------
commit fd41e6e9dfd302c7274e6f3bee6e5cc10dcb7b0a
Author: David Mitchell <[email protected]>
Date: Thu Apr 27 16:00:33 2017 +0100
add SHORT PVs
This commit adds an option for storing small strings (<16 bytes on a
64-bit system) directly in the XPV body of an SV.
It's still work-in-progress. It passes all tests, but could probably
benefit from optimisation work.
It's not enabled by default: perl must be built with the new cpp define
-DPERL_COPY_ON_WRITE3.
As the name implies, this commit is the first part of what's intended to
be a revamp of the COW implementation (COW1 was Nicholas's, COW2 was
sprout's; this is COW3).
The main things this commit does is:
1) Adds an extra pointer-sized field to the XPV structure and all those SV
types which inherit from it; so there's now (xpv_cur,xpv_len,extra)
instead of just (xpv_cur,xpv_len) in every string-capable body type.
2) Adds a new SV flag, SVf_SHORTPV, which indicates that the string is
stored directly in the body.
Under SVf_SHORTPV, sv_any points to the body as normal, but sv_u.svu_pv
points into the middle of the same body, where the (xpv_len,extra) fields
are used as a 16-byte buffer. xpv_cur still holds the current string
length.
The SvLEN() macro has been changed to return a constant value if
SVf_SHORTPV.
The SvCUR() and SvPVX() macros are unchanged.
Since derived string types like XPVIV also have the extra field, they can
hold a short string as well as an integer value.
When upgrading a SVf_SHORTPV SV to a new body type, the old body isn't
discarded but remains as the SV's string buffer, so sv_any and sv_u.svu_pv
now point to two different bodies. This means that code calling sv_upgrade
doesn't see the buffer address change. The old body will be freed when the
SV is freed.
Note that nothing under ext/, dist/ or cpan/ needed fixing apart from
ext/PerlIO-encoding/, which did some direct PVX buffer stealing.
(And Peek.t, obviously.)
The main breakages in core itself were places that directly moved a PVX
buffer from one SV to another: typically in the implementation of matching
and substitution - places such as pp_subst.
M dump.c
M embed.fnc
M ext/Devel-Peek/t/Peek.t
M ext/PerlIO-encoding/encoding.pm
M ext/PerlIO-encoding/encoding.xs
M gv.c
M perl.h
M pp_ctl.c
M pp_hot.c
M pp_pack.c
M proto.h
M regcomp.c
M regexec.c
M regexp.h
M sv.c
M sv.h
M toke.c
M universal.c
commit fed50a5daf335c1be2c6761b65abf201e1e3d735
Author: David Mitchell <[email protected]>
Date: Thu Mar 23 09:34:00 2017 +0000
PERL_DEBUG_PAD_ZERO(): use SvCUR_set()
M perl.h
commit 450eddb07edd30472c57930ab007838c87d22de6
Author: David Mitchell <[email protected]>
Date: Wed Mar 22 21:13:42 2017 +0000
fixup Perl_do_vop()
The memzero() has over the years inadvertently become nearly a noop,
zeroing only the single byte at the end; remove it for now.
Move the SvCUR_set() till after the SvGROW() if any, otherwise you have
cur temporarily pointing beyond the end of the buffer.
Not sure if these changes are 100% correct, but they pass all tests
M doop.c
commit 1a99ad059d0756e06a4871833f45cb8771c9f2e0
Author: David Mitchell <[email protected]>
Date: Wed May 3 21:15:26 2017 +0100
sv_chop() may reallocate buffer or shift bytes
Normally sv_chop() just uses the OOK mechanism to logically remove bytes
from the beginning of a string without physically moving anything.
However, it's possible for the sv_chop() to reallocate the buffer, so on
return the ptr arg and the original SvPVX(sv) may no longer point to
anything valid.
Later on in this branch it is hoped to introduce SVf_SHORTPV strings,
which sv_chop() will operate upon by moving bytes rather than activating
the OOP mechanism. This will make invalid ptr/SvPVX(sv) more common.
This commit does two things in preparation.
First, it tweaks the perlapi pod for sv_chop(): a comment about not
relying on the value SvPVX has been clarified;
second, a couple of callers of sv_chop in the perl core have been fixed
to not assume an invariant SvPVX buffer.
M pp_hot.c
M sv.c
-----------------------------------------------------------------------
--
Perl5 Master Repository
