summaryrefslogtreecommitdiff
path: root/sv.c
Commit message (Collapse)AuthorAgeFilesLines
* UTF8fFather Chrysostomos2013-06-181-1/+9
| | | | | | | | | | | | | | This new format string allows char*s to be interpolated with the utf8ness and length specified as well: Perl_croak(aTHX_ "Couldn't twiggle the twoggle in \"%"UTF8f"\"", is_utf8, len, s); This commit changes one function call in gv.c to use UTF8f (it should go faster now) as an example of its use. This was brought up in ticket #113824. This commit does not fix #113824, but provides groundwork that makes it easier to fix.
* Mark the common case with LIKELY branch predictor hintSteffen Mueller2013-06-181-1/+1
| | | | Freeing an SV usually indicates its refcount is 1.
* Don't use locale definitions unless within scopeKarl Williamson2013-06-171-5/+23
| | | | | | | | | | | | | Prior to this patch, stringification of an NV used the current locale's decimal point character, even outside the scope of a 'use locale'. This is contrary to the documentation (though one example in perllocale omitted the 'use locale') and can lead to unexpected results. There was one test in the core that relied on the old behavior, and maybe more in CPAN. This patch is being made early in 5.19 to see what breaks. I do believe though that any breakage is trumped by the principal that locale rules should only be used if locales are explicitly requested.
* PATCH: [perl #108378] [perl #115800]Karl Williamson2013-06-171-2/+10
| | | | | | | This patch solves two tickets. Both are a result of the stringification of a floating number being sticky, so that the character representing the decimal point may be from an old locale. The patch solves this by not retaining the stringification of NVs.
* Remove magic literal constant in favor of named constantSteffen Mueller2013-06-111-1/+2
| | | | For clarity only
* remove -Dmad string length restrictionDavid Mitchell2013-06-091-4/+0
| | | | | | | | Under -Dmad, with PERL_MADSKILLS > 0, it prints a warning for every string that is grown to be >= 1Mb. I can't see that it makes any sense to do this, so I suspect that this is residual code from MAD development, or an accidental copying of the almost identical #ifdef HAS_64K_LIMIT piece of code directly following it.
* Flush PL_stashcache on glob-to-glob assignmentFather Chrysostomos2013-06-081-0/+9
| | | | | | | | | | | | | | | | | Commit dc93d7fb33f6b2093 says this: Flush PL_stashcache when assigning a file handle to a typeglob. File handles take priority over stashes for method dispatch. Assigning a file handle to a typeglob potentially creates a file handle where one did not exist before. As PL_stashcache only con- tains entries for names which unambiguously resolve to stashes, such a change may mean that PL_stashcache now contains an invalid entry. As it’s hard to work out exactly which entries might be affected, simply flush the entire cache and let it rebuild itself. But it only applied to io-to-glob assignment. This commit extends it to glob-to-glob assignment.
* add 1 to SvGROW under COW (and fix svleak.t)David Mitchell2013-06-081-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the new COW scheme uses SvPVX(sv)[SvLEN(sv)-1] (if spare) to store the COW reference count. If this byte isn't spare, the string is copied rather than COWed. So, when built under the new COW, allocate one more byte than asked for in sv_grow(), to make it likely this byte is always spare: and thus make more strings COW-able. If the new size is a big power of two, don't bother: we assume the caller wanted a nice 2^N sized block and will be annoyed at getting 2^N+1 or more. Note that sv_grow() already rounds up. For example: formerly, strings of length 1..15 were allocated 16 bytes, 16..31 allocated 32 bytes, etc (usually allowing +1 for trailing \0). Now its 1..14 => 16, 15..30 => 32 etc. As a side-effect, this should fix a bizarre occasionally failing svleak.t test under COW. This test, '"too many errors" from constant overloading returning undef' basically twice evals some code that is expected to fail. If over the course of the second eval the total number of allocated SVs grows, then the test fails. This particular eval uses overload::constant, and that module has this code: "$_[1]" !~ /(^|=)CODE\(0x[0-9a-f]+\)$/ i.e. match against a stringified reference. Now, if it stringifies to a 15-char string (e.g. "CODE(0x1234567)"), then SvCUR is 15 and SvLEN is 16, and there isn't a spare byte (after allowing for \0) for the COW ref count, so the string can't be COWed. Now, if during the first eval, addresses are in the range 0x1000000..0xfffffff, then COW doesn't kick in. If during the second eval they fall outside this range, COW kicks in, and a new SV (which is a COW copy of the string) is attached to the regex, for capture info. This new SV won't be released until the regex is released, and so appears to be a leak. If COW kicks in during the first eval then this isn't an issue, as it will just be reused during the second eval. This was exceedingly difficult to reliably reproduce, as it was heavily affected by kernel address randomisation (on linux); plus part of the test file used rand(); plus of course the hash randomisation and perturbation feature in 5.18. I eventually cracked it by: tweaking the hash randomisation; hacking the perl seed code to use an ENV var rather than /dev/urandom; hacking the perl startup to display the initial system brk(), then when it failed, hacked it again to set that particular brk().
* [perl #117941] reset crashes when current stash is freedFather Chrysostomos2013-06-081-1/+1
|
* Stop using PL_sortstashFather Chrysostomos2013-06-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, the value of PL_sortstash was used to determine whether PL_firstgv and PL_secondgv (which point to *a and *b in the current package) needed to be updated (involving symbol lookup). PL_sortstash would contain the last package sorted in. If PL_sortstash did not point to the current stash, then they would be updated, along with PL_sortstash. Sort was made reëntrant in 2000 in commit 8e664e1028b. This involved saving and restoring the values of PL_firstgv and PL_secondgv via the savestack. The logic introduced by that commit was thus: + if (PL_sortstash != stash || !PL_firstgv || !PL_secondgv) { + SAVESPTR(PL_firstgv); + SAVESPTR(PL_secondgv); + PL_firstgv = gv_fetchpv("a", TRUE, SVt_PV); + PL_secondgv = gv_fetchpv("b", TRUE, SVt_PV); + PL_sortstash = stash; + } PL_firstgv and PL_secondgv would be null if no sort were already hap- pening, causing this block to be executed. For a nested sort, this would only be executed if the nested sort were in a different package from the outer sort. Because the value of PL_sortstash was not being restored, this block would not trigger the second time the outer sort called the inner sort (in a different package). This was bug #36430 (a duplicate of #7063). This was fixed in commit 9850bf21fc4e, which did not explain anything in its commit message. A preliminary version of the patch was submit- ted for review in <20051026173901.GA3105@rpc142.cs.man.ac.uk>, which mentions that the patch fixes bug #36430. It fixed the bug by localising the value of PL_sortstash, causing the if() condition to become redundant, so that was removed. Now, it happened that that if() condition was the only place that PL_sortstash was used. So if we are going to localise PL_firstgv and PL_secondgv unconditionally when sorting, PL_sortstash serves no purpose. While I could restore the if() condition and leave the localisation of PL_sortstash in place, that would only benefit code that does nested sort calls in the same package, which is rare, and the resulting speed-up is barely measurable. PL_sortstash is referenced by some CPAN modules, so I am taking the cautious route of leaving it in for now, though the core doesn’t use it.
* eliminate PL_regdummyDavid Mitchell2013-06-021-1/+0
| | | | | | | This global (per-interpreter) var is just used during regex compilation as a placeholder to point RExC_emit at during the first (non-emitting) pass, to indicate to not to emit anything. There's no need for it to be a global var: just add it as an extra field in the RExC_state_t struct instead.
* eliminate PL_reg_stateDavid Mitchell2013-06-021-14/+0
| | | | | | | | | | 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.
* make PL_reg_curpm globalDavid Mitchell2013-06-021-4/+1
| | | | | | | | | | | | | | | | | | Currently PL_reg_curpm is actually #deffed to a field within PL_reg_state; promote it into a fully autonomous perl-interpreter variable. PL_reg_curpm points to a fake PMOP that's used to temporarily point PL_curpm to, that we can hang the current regex off, so that this works: "a" =~ /^(.)(?{ print $1 })/ # prints 'a' It turns out that it doesn't need to be saved and restored when we recursively enter the regex engine; that is already handled by saving and restoring which regex is currently attached to PL_reg_curpm. So we just need a single global (per interpreter) placeholder. Since we're shortly going to get rid of PL_reg_state, we need to move it out of that struct.
* eliminate PL_reg_poscache, PL_reg_poscache_sizeDavid Mitchell2013-06-021-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* add regmatch_eval_state structDavid Mitchell2013-06-021-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace several PL_reg* vars with a new struct. This is part of the goal of removing all global regex state. These particular vars are used in the case of a regex with (?{}) code blocks. In this case, when the code in a block is called, various bits of state (such as $1, pos($_)) are temporarily set up, even though the match has not yet completed. This involves updating the current PL_curpm to point to a fake PMOP which points to the regex currently being executed. That regex has all its current fields that are associated with captures (such as subbeg) temporarily saved and overwritten with the current partial match results. Similarly, $_ is temporarily aliased to the current match string, and any old pos() position is saved. This saving was formerly done to the various PL_reg* vars. When the regex has finished executing (or if the code block croaks), its fields are restored to the original values. Since this can happen in a croak, it may be done using SAVEDESTRUCTOR_X() on the save stack. This precludes just moving the PL_reg* vars into the regmatch_info struct, since that is just allocated as a local var in regexec_flags(), and would have already been abandoned and possibly overwritten after the croak and longjmp, but before the SAVEDESTRUCTOR_X() action is taken. So instead we put all the vars into new struct, and malloc that on entry to the regex engine when we know we need to copy the various fields. We save a pointer to that in the regmatch_info struct, as well as passing it to SAVEDESTRUCTOR_X(). The destructor may get called up to twice in the non-croak case: first it's called explicitly at the end of regexec_flags(), which restores subbeg etc; then again from the savestack, which just free()s the struct. In the croak case, it's called just once, and does both the restoring and the freeing. The vars / PL_reg_state fields this commit eliminates are: re_state_eval_setup_done PL_reg_oldsaved PL_reg_oldsavedlen PL_reg_oldsavedoffset PL_reg_oldsavedcoffset PL_reg_magic PL_reg_oldpos PL_nrs PL_reg_oldcurpm
* eliminate PL_bostrDavid Mitchell2013-06-021-2/+0
| | | | | by moving it from the global PL_reg_state struct to the local reginfo struct.
* eliminiate PL_regeolDavid Mitchell2013-06-021-2/+0
| | | | | | | This is another global regex state variable (actually a field of PL_reg_state). Eliminate it by moving it into the regmatch_info struct instead, which is local to each match. Also, rename it to strend, which is a less misleading description in these exciting days of multi-line matches.
* Cache HvFILL() for larger hashes, and update on insertion/deletion.Nicholas Clark2013-05-291-0/+1
| | | | | | This avoids HvFILL() being O(n) for large n on large hashes, but also avoids storing the value of HvFILL() in smaller hashes (ie a memory overhead on every single object built using a hash.)
* Remove core references to SVt_BINDKarl Williamson2013-05-181-5/+5
| | | | | | This scalar type was unused. This is the first step in using the slot freed up for another purpose. The slot is now occupied by a temporary placeholder named SVt_DUMMY.
* Remove the non-inline function S_croak_memory_wrap from inline.h.Andy Dougherty2013-03-281-2/+2
| | | | | | | | | | | | | | | | | | | | This appears to resolve these three related tickets: [perl #116989] S_croak_memory_wrap breaks gcc warning flags detection [perl #117319] Can't include perl.h without linking to libperl [perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?) This patch changes S_croak_memory_wrap from a static (but not inline) function into an ordinary exported function Perl_croak_memory_wrap. This has the advantage of allowing programs (particuarly probes, such as in cflags.SH and Time::HiRes) to include perl.h without linking against libperl. Since it is not a static function defined within each compilation unit, the optimizer can no longer remove it when it's not needed or inline it as needed. This likely negates some of the savings that motivated the original commit 380f764c1ead36fe3602184804292711. However, calling the simpler function Perl_croak_memory_wrap() still does take less set-up than the previous version, so it may still be a slight win. Specific cross-platform measurements are welcome.
* Revert "Restore errno after VMS hack in S_sv_gets_read_record."Craig A. Berry2013-03-241-3/+0
| | | | | | | This reverts commit d46f021e36854e800770363f716e7b4a846102ef. This can be done more universally (and from the point of view of sv.c, less obtrusively) in Perl_flex_fstat in vms/vms.c.
* Restore errno after VMS hack in S_sv_gets_read_record.Craig A. Berry2013-03-221-0/+3
| | | | | | | | | | | | | | | | | | | | In 596a6cbd6bcaa8e6a4 I added a somewhat desperate hack to detect if a file is record-oriented so that we preserve record semantics when PL_rs has beeen set. I did it by calling fstat(), which is already a pretty icky thing to be doing on every record read, but it turns out things are even worse becaseu fstat() sets errno in some conditions where it's successful, specifically when the file is a Process-Permanent File (PPF), i.e., standard input or output. So save errno before the fstat and restore it before doing the read so if the read fails we get a proper errno. This gets t/io/errno.t passing. Side note: instead of fstat() here, we probably need to store a pointer to the FAB (File Access Block) in the PerlIO struct so all the metadata about the file is always accessible. This would require setting up completion routines in PerlIOUnix_open and PerlIOStdio_open.
* (UN)LIKELY branch prediction hints in a few strategic placesSteffen Mueller2013-03-061-4/+4
| | | | | | | | This adds branch prediction hints to a few strategic places such as growing stack or strings, some exception handling, and a few hot functions such as sv_upgrade. This is not exhaustive by any means.
* Prepare PL_sv_objcount removalSteffen Mueller2013-03-061-10/+0
| | | | | | | | | This used to keep track of all objects. At least by now, that is for no particularly good reason. Just because it could avoid a bit of work during global destruction if no objects remained. Let's do less work at run-time instead. The interpreter global will remain for one deprecation cycle.
* Set PL_stderrgv to NULL if it is freed.Nicholas Clark2013-03-061-0/+2
| | | | | Without this, it's possible to hit assertion failures when global destruction attempts to skip the PVIO for PL_stderrgv while cleaning up all objects.
* Remove dead code in Perl_sv_cmp_flagsSteffen Mueller2013-01-311-3/+0
| | | | Most certainly compiled away anyway, but still dead.
* include SvREADONLY() in SvIMMORTAL() testDavid Mitchell2013-01-121-4/+4
| | | | | | | | | | | | | | | | SvIMMORTAL() is currently defined as ((sv)==&PL_sv_undef || (sv)==&PL_sv_yes || (sv)==&PL_sv_no || (sv)==&PL_sv_placeholder) Which is relatively slow. Some places do this: if (SvREADONLY(sv) && SvIMMORTAL(sv)) ... which quickly rejects most times. This commit simply moves the SvREADONLY test into the SvIMMORTAL macro so that *all* uses benefit from this speedup.
* regex: Add pseudo-Posix class: 'cased'Karl Williamson2012-12-311-1/+0
| | | | | | | | | | | | | | | | | /[[:upper:]]/i and /[[:lower:]]/i should match the Unicode property \p{Cased}. This commit introduces a pseudo-Posix class, internally named 'cased', to represent this. This class isn't specifiable by the user, except through using either /[[:upper:]]/i or /[[:lower:]]/i. Debug output will say ':cased:'. The regex parsing either of :lower: or :upper: will change them into :cased:, where already existing logic can handle this, just like any other class. This commit fixes the regression introduced in 3018b823898645e44b8c37c70ac5c6302b031381, and that these have never worked under 'use locale'. The next commit will un-TODO the tests for these things.
* handy.h: Add full complement of isIDCONT() macrosKarl Williamson2012-12-231-0/+1
| | | | | | | This also changes isIDCONT_utf8() to use the Perl definition, which excludes any \W characters (the Unicode definition includes a few of these). Tests are also added. These macros remain undocumented for now.
* Use an array for some inversion listsKarl Williamson2012-12-221-7/+1
| | | | | Previous commits have placed some inversion list pointers into arrays. This commit extends that to another group of inversion lists
* Use an array for some inversion listsKarl Williamson2012-12-221-29/+1
| | | | | An earlier commit placed some inversion list pointers into an array. This commit extends that to another group of inversion lists.
* Use array for some inversion listsKarl Williamson2012-12-221-8/+3
| | | | | | This patch creates an array pointing to the inversion lists that cover the Latin-1 ranges for Posix character classes, and uses it instead of the individual variables previously referred to.
* intrpvar.h: Place some swash pointers in an arrayKarl Williamson2012-12-221-9/+3
|
* Better POD for newSVrvDaniel Dragan2012-12-201-4/+4
| | | | | | | | | | | It takes me a couple times to slowly read the description to realize what this does. The "its reference count is 1" can be misread to mean someone must mortalize the return value of newSVrv. The "Creates a new SV for the RV, C<rv>, to point to." can be misread to mean that newSVrv is a macro, and will do an &() on rv to create a total of two new SVs. An SvRV pointing to a posssibly blessed undef SV. This is also wrong. Adding "existing" makes the point that rv will not be created in this call.
* test the resetting of refcnt for immortalsDavid Mitchell2012-12-181-6/+6
| | | | | | | | PL_sv_undef etc get given a very high ref count, which if it ever reaches zero, is set back to a high value. On debugging builds, use a lower value (1000) so that the resetting code gets exercised occasionally. Also, replace literal (~(U32)0)/2 with the constant SvREFCNT_IMMORTAL.
* regexec.c: More efficient Korean \X processingKarl Williamson2012-12-161-1/+0
| | | | | | This refactors the code slightly that checks for Korean precomposed syllables in \X. It eliminates the PL_variable formerly used to keep track of things.
* Zap PL_glob_indexFather Chrysostomos2012-12-091-1/+0
| | | | As of the previous commit, nothing is using it.
* Convert some SvREFCNT_dec's to SvREFCNT_dec_NN's for efficiencySteffen Mueller2012-12-091-18/+18
|
* Add functions for getting ctype ALNUMCKarl Williamson2012-12-091-0/+1
| | | | | | | We think this is meant to stand for C's alphanumeric, that is what is matched by POSIX [:alnum:]. There were not functions and a dedicated swash available for accessing it. Future commits will want to use these.
* Only handle PL_rs differently on VMS for record-oriented files.Craig A. Berry2012-12-091-10/+19
| | | | | | | | | | For stream-oriented files, the effects of buffering and other layers should be exactly as they are on other platforms. For true, record-oriented files, though, setting $/ = \number must provide exactly one low-level read per record. If a read were ever to return less than a full record (due to, for example, filling up the perlio buffer), a subsequent read would get the *next* record, losing whatever data remained in the partially-read record.
* no need to FIXME, it behaves like read() which is the intentTony Cook2012-12-091-4/+5
| | | | | except read() doesn't complain about the invalid characters like sv_gets().
* fix another boundary case and hopefully improve performanceTony Cook2012-12-091-4/+17
| | | | | | | | | | | | | | | The fix: the if we found ourselves at a charstart with only one character to read, readsize would be zero, handle that correctly. Performance: originally I read just the first byte of the next character, which meant as many extra read calls as there are characters left to read after the initial read. So O(Nleft) reads where Nleft is the number of characters left to read after the initial read. Now read as many bytes as there are characters left to read, which should mean the number of reads comes down to O(log(Nleft**2)) I think (but don't ask me to justify that.)
* fix a fencepost error I found trying to fall asleepTony Cook2012-12-091-2/+3
|
* Incomplete implementation of $/ = \number acting like read()Tony Cook2012-12-091-1/+59
| | | | | | | | | | | | | | It's under tested, and incomplete - readline appears to ignore IN_BYTES, so this code continues to do so. - currently :utf8 will return invalid utf8, which means this can too, if we can be sure of :utf8 returning only valud utf-8 the FIXME can be ignored - VMS is the elephant in the room - the conditional means that the new code is completely ignored for reading from files. If we can detect record-oriented files in some way this could change.
* die, evil [IU]32Tony Cook2012-12-091-2/+2
| | | | It's still not as dead as I'd like.
* sv.c: Correct newSVpvn_share docsFather Chrysostomos2012-12-051-1/+2
| | | | something I overlooked
* make SvREFCNT_dec() more efficientDavid Mitchell2012-12-041-56/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, SvREFCNT_dec was just #define SvREFCNT_dec(sv) sv_free((SV*)(sv)) then in 5.10.0, for GCC, the macro was partially inlined, avoiding a function call for the refcnt > 1 case. Recently, the macro was turned into an inline function, providing the function-call avoidance to other platforms too. However, the macro/inline-function is quite big, and appears over 500 times in the core source. Its action is logically equivalent to: if (sv) { if (SvREFCNT(sv) > 1) SvREFCNT(sv)--; else if (SvREFCNT == 1) { // normal case SvREFCNT(sv)--; sv_free2(sv); } else { // exceptional case sv_free(sv); } } Where sv_free2() handles the "normal" quick cases, while sv_free() handles the odd cases (e,g. a ref count already at 0 during global destruction). This means we have to plant code that potentially calls two different subs, over 500 times. This commit changes SvREFCNT_dec and sv_free2() to look like: PERL_STATIC_INLINE void S_SvREFCNT_dec(pTHX_ SV *sv) { if (sv) { U32 rc = SvREFCNT(sv); if (rc > 1) SvREFCNT(sv) = rc - 1; else Perl_sv_free2(aTHX_ sv, rc); } } Perl_sv_free2(pTHX_ SV *const sv, const U32 rc) { if (rc == 1) { SvREFCNT(sv) = 0; ... do sv_clear, del_SV etc ... return } /* handle exceptional rc == 0 */ ... } So for the normal cases (rc > 1, rc == 1) there is the same amount of testing and function calls, but the second test has been moved inside the sv_free2() function. This makes the perl executable about 10-15K smaller, and apparently a bit faster (modulo the fact that most benchmarks are just measuring noise). The refcount is passed as a second arg to sv_free2(), as on platforms that pass the first few args in registers, it saves reading sv->sv_refcnt again.
* Add SS_ADD_* macros and replace most SSPUSH* usesDavid Mitchell2012-12-041-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 */
* Clear method caches when unwinding local *foo=sub{}Father Chrysostomos2012-11-291-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Reset method caches when GPs are sharedFather Chrysostomos2012-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new MRO stuff in 5.10 made PL_sub_generation++ mostly unnecessary, and almost all uses of it were replaced with mro_method_changed_in. There is only one problem: That doesn’t actually work properly. After glob-to-glob assignment (*foo = *bar), both globs share the same GP (glob pointer, or list of glob slots). But there is no list of GVs associated with any GP. So there is no way, given a GV whose GP is shared, to find out what other classes might need their method caches reset. sub B::b { "b" } *A::b = *B::b; @C::ISA = "A"; print C->b, "\n"; # should print "b" eval 'sub B::b { "c" }'; print C->b, "\n"; # should print "c" __END__ $ perl5.8.9 foo b c $ perl5.10.0 foo b b And it continues up to 5.16.x. If a GP is shared, then those places where mro_method_changed_in is called after the GP has been modified must do PL_sub_generation++ instead if the GP is shared, which can be detected through its refer- ence count.
View Lorry Controller Status