summaryrefslogtreecommitdiff
path: root/sv.h
Commit message (Collapse)AuthorAgeFilesLines
* perlapi: Add 2 links to other parts of the podKarl Williamson2015-05-081-0/+3
|
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* improve SvPV_set's docs, it really shouldn't be public APIDaniel Dragan2015-01-191-3/+8
| | | | | | | Someone else in the perl community wrote XS code using SvPV_set instead of sv_setpvn and couldn't figure out why he was getting heap corruption/failed asserts/SEGVs/etc. Improve the docs to basically say never use this.
* More branch prediction hints for sv_setsv_flagsSteffen Mueller2014-12-011-1/+1
| | | | | | | | | | | | | | | Dave's cachegrind benchmark says "small win": REF THIS ------ ------ Ir 105.35 105.91 Dr 104.45 105.42 Dw 105.42 105.17 COND 104.33 104.58 IND 107.04 106.76 COND_m 98.55 110.11 IND_m 110.09 111.08
* [perl #123223] Make PADNAME a separate typeFather Chrysostomos2014-11-301-63/+7
| | | | | | | | | | | 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.
* Make PADNAMELIST a separate typeFather Chrysostomos2014-11-301-2/+1
| | | | This is in preparation for making PADNAME a separate type.
* Use PADNAME rather than SV in the sourceFather Chrysostomos2014-11-301-1/+1
| | | | | | | | | This is in preparation for making PADNAME a separate type. This commit is not perfect. What I did was temporarily make PADNAME a separate struct identical to struct sv and make whatever changes were necessary to avoid compiler warnings. In some cases I had to add tem- porary SV casts.
* remove a branch in SvIV_please_nomgDaniel Dragan2014-11-241-3/+3
| | | | | | | | | | | | | | | | On VC 2003 and GCC 4.6.3, this patch decreases from 3 branches to 2 branches that machine code that makes up SvIV_please_nomg. Functionality should be identical as before. This is intended to make math functions like pp_add faster. Due to complexity/my time, SvIV_please wasn't optimized. "(SvNOK(sv) || SvPOK(sv)" was optimized to "(SvFLAGS(sv) & (SVf_NOK|SVf_POK))" on GCC and VC 2003 before this patch, so that change reenforces what the optimizer already did before. .text section of miniperl.exe size in bytes gcc 32b 4.6.3 -O2 before 0x10d154 gcc 32b 4.6.3 -O2 after 0x10d064 vc2003 before 0xa4odf vc2003 after 0xa406f
* Add new LVALUE flag for pad namesFather Chrysostomos2014-11-131-0/+2
| | | | | This will be used to record whether a pad entry is used as an lvalue multiple times. If so, it cannot be used as a constant.
* add xs_handshake APIDaniel Dragan2014-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This API elevates the amount of ABI compatibility protection between XS modules and the interp. It also makes each boot XSUB smaller in machine code by removing function calls and factoring out code into the new Perl_xs_handshake and Perl_xs_epilog functions. sv.c : - revise padlist duping code to reduce code bloat/asserts on DEBUGGING ext/DynaLoader/dlutils.c : - disable version checking so interp startup is faster, ABI mismatches are impossible because DynaLoader is never available as a shared library ext/XS-APItest/XSUB-redefined-macros.xs : - "" means dont check the version, so switch to " " to make the test in xsub_h.t pass, see ML thread "XS_APIVERSION_BOOTCHECK and XS_VERSION is CPP defined but "", mow what?" ext/re/re.xs : - disable API version checking until #123007 is resolved ParseXS/Utilities.pm : 109-standard_XS_defs.t : - remove context from S_croak_xs_usage similar to core commit cb077ed296 . CvGV doesn't need a context until 5.21.4 and commit ae77754ae2 and by then core's croak_xs_uage API has been long available and this backport doesn't need to account for newer perls - fix test where lack of having PERL_IMPLICIT_CONTEXT caused it to fail
* free up CvPADLIST slot for XSUBs for future useDaniel Dragan2014-10-311-1/+4
| | | | | | | | | | | | | | | | | | | CvRESERVED is a placeholder, it will be replaced with a sentinal value from future revised BOOTCHECK API. CvPADLIST_set was helpful during development of this patch, so keep it around for now. PoisonPADLIST's magic value is from PERL_POISON 0xEF pattern. Some PoisonPADLIST locations will get code from future BOOTCHECK API. Make padlist_dup a NN function to avoid overhead of calling it for XSUBs during closing. Perl_cv_undef_flags's else if (CvISXSUB(&cvbody)) is to avoid whitespace changes. Filed as perl [#123059].
* Apify SV_CATBYTES and SV_CATUTF8Father Chrysostomos2014-10-181-6/+2
| | | | | | | When I added them I was not sure at the time whether they would be stable or whether they might need to be changed. They seem pretty stable now, and they are extremely useful, so make them part of the API.
* optimize SV creation funcs in sv.cDaniel Dragan2014-10-041-0/+3
| | | | | | | | | | | | | | | | | | | | In Perl_newSV, the sv_upgrade is redundant, except to protect against a segv in blindly SV body derefing SvGROW (but not in sv_grow). sv_grow has always upgraded a non-PV SV to PV. So don't it here. Since a new SV will never have be a COW, have a SvLEN or a body, all of which SvGROW uses, just call sv_grow. Less branching, and smaller code that way. In Perl_newSV_type, give a hint to compiler that if a platform's symbol visibility allows inlining, and newSV_type's arg is the base type (currently SVt_NULL, maybe SVt_IV in future (see ML)), to possibly inline new_SV into the caller and remove the sv_upgrade call. Also don't call sv_upgrade if it isn't needed (SVt_NULL) in the public symbol version. The redundant sv_upgrade then sv_grow goes to commit 79072805bf "perl 5.0 alpha 2". VC 2003 -01 32 bit threaded machine code size in bytes of 2 functions Perl_newSV_type before 0x2f after 0x29 Perl_newSV before 0x48 after 0x28
* for storage of NVs, use "IV in sv_u in head no-body trick" where possibleDaniel Dragan2014-09-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | This completes the goal of commit 7b2c381cf3 from 5.9.2/2005. 8 bytes are saved on arena and 8 byte double is NV builds, and usually 32 bytes on PURIFY/malloced bodies builds. (2 void *s/16 bytes for header+16 bytes minimum malloc size on typical malloc schemes). long doubles can't use this optimization. Also a hypothetical NV is 32 bit float on 32 bit pointer OS Perl build would use this optimization. 64 bit IVs on 32 bit pointer OS use this optimization. Also fixed was a bad solution from ML post "[PATCH] Free old_body in sv_upgrade, also with -DPURIFY" commit bc78644842 which made the old body freeing code in sv_upgrade not obey the body_details table. By checking allocation size instead whether there is an arena better determins if there there is a body to free, PURIFY or not. Note the upper SV types that are malloced/no arena are not upgradable so this code wont be reached due to earlier croak, so there is no danger of an arena ptr getting a free() done on it. This author doesnt have access to PURIFY. Also remove padding from body_details struct. On Win64, this struct was 16 bytes, in format of U8 U8 U8 PAD1BYTE U32 U64. On Win32 it was 12 bytes long, in format of U8 U8 U8 PAD1BYTE U32 U32. Now on compilers (such as VC) that allow 1 byte C bitfields (non-standard extension to C), the struct is always 8 bytes long. I can't imagine an arena being >4GB on 64 bit perl.
* Remove most uses of PADMYFather Chrysostomos2014-09-241-3/+5
| | | | SVs_PADMY is now 0, and SvPADMY means !SvPADTMP.
* Stop setting PADMY; renumber PADSTALEFather Chrysostomos2014-09-241-11/+8
| | | | | | | | | | | | | | | | | | | | 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
* SvFLAGS: informally reserve a bitDavid Mitchell2014-09-221-2/+4
| | | | | | | SvFAKE is currently unused on HVs, so I'm marking it as mine. Hopefully it will eventually get used for vtables on HVs. I've also improved the description of SVs_TEMP.
* Consistent spaces after dots in perlapiFather Chrysostomos2014-09-211-1/+1
|
* Implement the bipolar read-only systemFather Chrysostomos2014-09-201-6/+12
| | | | | | | | | | | | | | | | | | | | | 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.)
* Add SVf_PROTECTFather Chrysostomos2014-09-201-0/+1
|
* Renumber SVf_IsCOWFather Chrysostomos2014-09-201-5/+3
| | | | and free up a bit.
* Parenthesize & and | a bit.Jarkko Hietaniemi2014-09-181-3/+3
|
* sv.h: Expand comment about potential SVf_UTF8 conflictFather Chrysostomos2014-09-151-1/+2
|
* sv_cathekFather Chrysostomos2014-09-151-0/+6
| | | | | This macro, intended for internal use, simplifies the code in a couple of places.
* sv.h: Document SVt_INVLIST fieldsKarl Williamson2014-07-211-3/+8
|
* be explicit that SvSetSV() doesn't do set magicTony Cook2014-06-171-1/+1
|
* perlapi: Nit, and mention NUL for some functionsKarl Williamson2014-06-071-2/+3
| | | | | This adds the mention of embedded or terminating NULs for some functions where it wasn't previously indicated.
* perlapi: Clarify some instances where NUL is or isn't permittedKarl Williamson2014-05-301-1/+2
| | | | | | Some functions that take a string/length pair can have embedded NULs and don't have to be NUL terminated; others are the opposite. This adds text to clarify the issue.
* Wrap various pod uses of NUL with C<>Karl Williamson2014-05-301-2/+2
| | | | | | This makes the uses of this consistent in our pods. Also changed one use of the word 'buffer' into 'string', the latter being more appropriate.
* clarify SvPV documentationDavid Golden2014-05-131-2/+4
|
* Implement "max waste" thresholds to avoid problems with COW and deliberately ↵Yves Orton2014-05-121-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | overallocated pvs COW does not play nicely with "preallocate" algorithms. More specifically code like sv_gets() wants to preallocate a large buffer into $_ for performance reasons. Prior to COW this was just fine. When someone assigned $_ to a less volatile variable only the used portion of the buffer was copied, and the extended buffer would be reused by sv_gets() and all was well. With COW however this process is foiled. The preallocated buffer get shared, and then when $_ is updated the buffer is dropped from $_, leaving the other SV holding ownership of the overallocated buffer, and causing sv_gets() to allocate a new buffer entirely. This process would then repeat consuming time and lots of memory. This patch introduces a "wastage" check to COW. When decided if we should COW a string we look at the ratio and difference of SvCUR(sv) and SvLEN(sv), which represent the "actual string length" and the "allocated string length". When the difference exceeds a hard threshold, or when the ration exceeds a designated factor then we do not COW. This means that strings with large overallocations are not COWed. Exactly how this works out in practice, where SvGROW() *always* overallocates, is an open question. See: https://rt.perl.org/Ticket/Display.html?id=121796 This patch also slightly tweaks SvGROW() not to do roundup on the first allocation of the pv. Odds are good that the initial request realy does want exactly what they expected. (SvGROW contrary to what the name suggests is used for bother *extended* the size of a pv, and initializing it the first time.)
* sprinkle LIKELY() on pp_hot.c scope.c and some *.hDavid Mitchell2014-03-121-12/+12
| | | | | | | | 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.
* sv.h: add some more flag usage commentaryDavid Mitchell2014-03-071-5/+8
| | | | | Also, move SVphv_SHAREKEYS up to be closer to SVf_UTF8 - they are the same flag bit, but it wasn't clear, since there was a big gap between them
* gv_check(): use aux flag rather than IsCOWDavid Mitchell2014-02-281-1/+0
| | | | | | | | | | Currently the SVf_IsCOW flag doesn't have any meaning for HVs, except that it is used in the specific case of gv_check() to temporarily mark a stash as being scanned. Since stashes will have the HV_AUX fields, we can use a flags bit in the new xhv_aux_flags field instead. This then potentially frees up the SVf_IsCOW for use as a new general flag bit for *all* HVs (including non-stash ones).
* sv.h: Add commentKarl Williamson2014-02-161-0/+1
| | | | There was recent confusion about this.
* Fix small typo (dsb -> dsv)Matthew Horsfall (alh)2014-02-141-2/+2
|
* Avoid compiler warnings by consistently using #ifdef instead of plain #ifBrian Fraser2014-02-051-1/+1
|
* SvGROW should un-cow under PERL_OLD_COPY_ON_WRITEFather Chrysostomos2014-01-161-1/+1
| | | | | | | Otherwise pp_uc (and presumably other pieces of code) will end up mod- ifying shared buffers. Brought to you by PERL_DEBUG_READONLY_COW.
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-8/+11
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* Revert "make perl core quiet under -Wfloat-equal"David Mitchell2013-11-161-1/+1
| | | | | | | | | | | A suggested way of avoiding the the warning on nv1 != nv2 by replacing it with (nv1 < nv2 || nv1 > nv2), has too many issues with NaN. [perl #120538]. I haven't found any other way of selectively disabling the warning, so for now I'm just reverting the whole commit. This reverts commit c279c4550ce59702722d0921739b1a1b92701b0d.
* make perl core quiet under -Wfloat-equalDavid Mitchell2013-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | The gcc option -Wfloat-equal warns when two floating-point numbers are directly compared for equality or inequality, the idea being that this is usually a logic error, and that you should be checking that the values are instead very near to each other. perl on the other hand has lots of reasons to do a direct comparison. Add two macros, NV_eq_nowarn(a,b) and NV_eq_nowarn(a,b) that do the same as (a == b) and (a != b), but without the warnings. They achieve this by instead doing (a < b) || ( a > b). Under gcc at least, this is optimised into the same code as the direct comparison. The are three places that I've left untouched, because they are handling NaNs, and that gets a bit tricky. In particular (nv != nv) is a test for a NaN, and replacing it with (< || >) creates signalling NaNs (whereas == and != create quiet NaNs)
* correct POD for SvIsCOW, it returns a U32Daniel Dragan2013-10-231-2/+2
|
* sv.h: Make BmUSEFUL the same type on debug/non-debug buildsFather Chrysostomos2013-09-151-1/+1
| | | | | 408dc2ec1c7 made in an IV (signed) on debugging builds but a UV (unsigned) on regular builds.
* Move BmUSEFUL to the IV slot from the NV slot, simplifying union _xnvu.Nicholas Clark2013-09-131-5/+4
| | | | | This change is made possible by commit 8922e4382e9c1488 (June 2013), which eliminated BmPREVIOUS, which had been using the IV slot.
* [perl #119481] Check SvVALID for !SvSCREAM, skip PADReini Urban2013-09-031-4/+7
| | | | | | | SVpad_NAME = SVp_SCREAM|SVpbm_VALID Subsequently OUR, TYPED and STATE pads all have SVp_SCREAM set. SVpad_NAME shares the same bit with SVpbm_VALID, so avoid checking PADs for SVpbm_VALID.
* Stop pos() from being confused by changing utf8nessFather Chrysostomos2013-08-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | The value of pos() is stored as a byte offset. If it is stored on a tied variable or a reference (or glob), then the stringification could change, resulting in pos() now pointing to a different character off- set or pointing to the middle of a character: $ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, a; print pos $x' 2 $ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, "\x{1000}"; print pos $x' Malformed UTF-8 character (unexpected end of string) in match position at -e line 1. 0 So pos() should be stored as a character offset. The regular expression engine expects byte offsets always, so allow it to store bytes when possible (a pure non-magical string) but use char- acters otherwise. This does result in more complexity than I should like, but the alter- native (always storing a character offset) would slow down regular expressions, which is a big no-no.
* [perl #118691] Allow defelem magic with neg indicesFather Chrysostomos2013-08-211-1/+7
| | | | | | | | | | | | | | | | | | | | | | When a nonexistent array element is passed to a subroutine, a special ‘deferred element’ scalar (implemented using something called defelem magic) is passed to the subroutine instead, which delegates to the array element. This allows some_benign_function($array[$nonexistent]) to avoid autovivifying unnecessarily. Whether this magic would be triggered was based on whether the element was within the range 0..$#array. Since arrays can contain nonexistent elements before $#array, this logic is incorrect. It also makes sense to allow $array[$neg] where the negative number points before the beginning of the array to create a deferred element and only croak if it is assigned to. This commit fixes the logic for when deferred elements are created and implements these deferred negative elements. Since we have to be able to store negative values in xlv_targoff, it is convenient to make it a union (with two types--signed and unsigned) and use LvSTARGOFF for defelem array indices.
* sv.h: Add comment about gv_check and SvIsCOWFather Chrysostomos2013-08-061-0/+1
| | | | | So that future refactorings don’t make use of 0x00010000 on hashes without modifying gv_check to account.
* Skip trailing constants when searching padsFather Chrysostomos2013-07-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under ithreads, constants and GVs are stored in the pad. When names are looked up up in a pad, the search begins at the end and works its way toward the beginning, so that an $x declared later masks one declared earlier. If there are many constants at the end of the pad, which can happen for generated code such as lib/unicore/TestProp.pl (which has about 100,000 lines and over 500,000 pad entries for constants at the end of the file scope’s pad), it can take a long time to search through them all. Before commit 325e1816, constants used &PL_sv_undef ‘names’. Since that is the default value for array elements (when viewed directly through AvARRAY, rather than av_fetch), the pad allocation code did not even bother storing the ‘name’ for these. So the name pad (aka padnamelist) was not extended, leaving just 10 entries or so in the case of lib/unicore/TestProp.pl. Commit 325e1816 make pad constants have &PL_sv_no names, so the name pad would be implicitly extended as a result of storing &PL_sv_no, causing a huge slowdown in t/re/uniprops.t (which runs lib/unicore/TestProp.pl) under threaded builds. Now, normally the name pad *does* get extended to match the pad, in pad_tidy, but that is skipped for string eval (and required file scope, of course). Hence, wrapping the contents of lib/unicore/TestProp.pl in a sub or adding ‘my $x’ to end of it will cause the same slowdown before 325e1816. lib/unicore/TestProp.pl just happened to be written (ok, generated) in such a way that it ended up with a small name pad. This commit fixes things to make them as fast as before by recording the index of the last named variable in the pad. Anything following that is disregarded in pad lookup and search begins with the last named variable. (This actually does make things faster before for subs with many trailing constants in the pad.) This is not a complete fix. Adding ‘my $x’ to the end of a large file like lib/unicore/TestProp.pl will make it just as slow again. Ultimately we need another algorithm, such as a binary search.
* sv.h: Comments added/typo fixed.Karl Williamson2013-07-191-1/+8
|
View Lorry Controller Status