summaryrefslogtreecommitdiff
path: root/hv.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Clean: Move old comment to proper locationMichael Witten2011-03-191-6/+6
| | | | | | | | | | | | | | | | This: commit 0298d7b92741692bcf2e34c418a564332bb034e6: Date: Tue May 31 10:40:01 2005 +0000 Avoid updating a variable in a loop. Only calculate the number of links in a hash bucket chain if we really need it. p4raw-id: //depot/perl@24648 forgot to move a large comment to its new location; this new commit fixes that.
* Fix typos (spelling errors) in Perl sources.Peter J. Acklam) (via RT2011-01-071-1/+1
| | | | | | | | | # New Ticket Created by (Peter J. Acklam) # Please include the string: [perl #81904] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 > Signed-off-by: Abigail <abigail@abigail.be>
* Fix compiler warning in hv.c on MSWin32Jerry D. Hedden2010-12-011-1/+1
| | | | | | | Fixes the following seen in a Steve Hay smoke test: Compiler messages(MSWin32): ..\hv.c(1646) : warning C4244: 'initializing' : conversion from 'unsigned long ' to 'const char ', possible loss of data
* Fix memory leak in hfreeentriesFather Chrysostomos2010-11-301-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change that made hfreeentries keep the name in place when iterat- ing (2d0d1ecc) caused this statement at the end of the loop to be a no-op for named hashes, because the HvARRAY is always present at the end of the loop (it contains the name): if (!HvARRAY(hv)) { /* Good. No-one added anything this time round. */ break; } So this line was added (by the same change) before the freeing of the linked lists: /* If there are no keys, there is nothing left to free. */ if (!((XPVHV*) SvANY(hv))->xhv_keys) break; But that means that this, immediately after the freeing of the linked lists and just before the if(!HvARRAY(hv)): if (array != orig_array) { Safefree(array); } was not being reached, resulting in a memory leak (that Nicholas Clark found). This is what would happen: On entering hfreeentries, orig_array would be assigned the value in HvARRAY. HvARRAY = original array orig_array = original array Then the main loop would be entered, which would assign HvARRAY to array: HvARRAY = original array orig_array = original array array = original array HvARRAY would be nulled out and assigned a new value by hv_auxinit: HvARRAY = first new array orig_array = original array array = original array Then the loop would repeat: HvARRAY = first new array orig_array = original array array = first new array Then the HvARRAY would once more be nulled and replaced via hv_auxinit: HvARRAY = second new array orig_array = original array array = first new array Then the if(no keys)break; statement would be reached, exit- ing the loop: HvARRAY = second new array orig_array = original array <nothing> = first new array So the first new array is never freed. This commit skips the allocation of an extra array at the beginning of the loop if there are no keys. Then it exits early at the same spot.
* Use newSVpvs_flags() instead of sv_2mortal(newSVpvs())Nicholas Clark2010-11-251-1/+1
| | | | And similarly for newSVpvn() for a known length.
* Convert xhv_name in struct xpvhv_aux to be a union of HEK* and HEK**Nicholas Clark2010-11-241-36/+47
| | | | | This avoids a lot of casting. Nothing outside the perl core code is accessing that member directly.
* Add flags param to hv_ename_*Father Chrysostomos2010-11-201-2/+4
| | | | | We will need this for making the API UTF8-aware in 5.16 or whenever.
* S_hfreeentries: keep OOK off unless adding something to auxFather Chrysostomos2010-11-201-1/+1
| | | | | This small optimisation allows hv_undef to skips its if(SvOOK()) block and all the checks inside it much of the time.
* Eliminate the newname param from mro_package_movedFather Chrysostomos2010-11-201-2/+2
| | | | Nothing is using this any more, as of the previous commit.
* Make hv_undef leave HvENAME aloneFather Chrysostomos2010-11-201-20/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unless called from sv_clear. This is necessary as and undeffed stash, though it nominally becomes just a plain hash and is not a stash any more, is still to be found in the symbol table. It may even be in multiple places. HvENAME’s raison d’être is to keep track of this. If the effective name is deleted, then things can get out of sync as the test in the commit demonstrates. This can cause problems if the hash is turned back into a stash. This does not change the deletion of the HvNAME, which is the only difference between hv_clear and hv_undef on stashes that is visible from Perl. caller still returns (unknown) or __ANON__::.... I tried to make this into several small commits, but each part of it breaks things without the other parts, so this is one big commit. These are the various parts: • hv_undef no longer calls mro_package_named directly, as it deletes the effective name of the stash. It must only be called on sub- stashes, so hfreeentries has been modified to do that. • hv_name_set, which has erased the HvENAME when passed a null arg for the value ever since effective names were added (a special case put it just for hv_undef), now leaves the HvENAME alone, unless the new HV_NAME_SETALL flag (set to 2 to allow for UTF8 in future) is passed. • hv_undef does not delete the name before the call to hfreeentries during global destruction. That extra name deletion was added when hfreeentries stopped hiding the name, as CVs won’t be anonymised properly if they see it. It does not matter where the CVs point if they are to be freed shortly. This is just a speed optimisation, as it allows the name and effective name to be deleted in one fell swoop. Deleting just the name (not the effective name) can require a memory allocation. • hv_undef calls mro_isa_changed_in as it used to (before it started using mro_package_moved), but now it happens after the entries are freed. Calling it first, as 5.13.6 and earlier versions did, was simply wrong. • Both names are deleted from PL_stashcache. I inadvertently switched it back and forth between the two names in previous commits. Since it needed to be accounted for, it made no omit it, as that would just complicate things. (I think PL_stashcache is buggy, though I have yet to come up with a test case.) • sv_clear now calls Perl_hv_undef_flags with the HV_NAME_SETALL flag, which is passed through to the second hv_name_set call, after hfreeentries. That determines whether the effective names are deleted. • The changes at the end of hv_undef consist of pussyfooting to avoid unnecessary work. They make sure that everything is freed that needs to be and nothing is freed that must not be.
* hv_undef .= _flagsFather Chrysostomos2010-11-201-1/+1
| | | | | | | Add flags param to hv_undef. There is no mathom, as the changes that this will support are by no means suitable for maint.
* Fix hv_name_set when there is an HvENAMEFather Chrysostomos2010-11-201-4/+7
| | | | | This code was completely wrong and could even crash. This is not cur- rently reached.
* Don’t skip mro_package_moved if the parent stash is renamedFather Chrysostomos2010-11-161-22/+10
| | | | | | | This stops S_hv_delete_common from skipping the call to mro_package_moved if the HvNAME of the stash containing the deleted glob is no longer valid, but the stash is still attached to some other part of the symbol table.
* Fix memory leak introduced by 2d0d1eccfcfeFather Chrysostomos2010-11-151-2/+2
| | | | | If HvENAME was set by a destructor, it needs to be freed as well. hv_name_set(whatever, NULL, ...) does that.
* Keep MRO caches around during hv_clearFather Chrysostomos2010-11-151-25/+33
| | | | | | | This allows it to delete PL_isarev entries. mro_isa_changed_in only deletes items mentioned in HvMROMETA(hv)->isa, so it must be present.
* [perl #79208] %stash:: = () anonymises CVsFather Chrysostomos2010-11-151-54/+54
| | | | | | | | | | | | | This keeps stash names visible during %foo:: = (). This fixes @ISA assignment inside a DESTROY method triggered by %foo:: = () and also lets existing CVs retain their pointers to the stash. So %foo:: = () is now equivalent to delete $foo::{$_} for keys %foo::
* Eliminate PL_dirtyFlorian Ragwitz2010-11-141-1/+1
| | | | | It now only exists as a compatibility macro for extensions that want to introspect it.
* Fix undef %Foo:: to update subclassesFather Chrysostomos2010-11-131-1/+6
| | | | | | | | | | | This is something I think I broke with 80ebaca, which made sure that isa linearisations were cached on subclasses after calls to mro_isa_changed_in (so the data could be used to delete isarev entries). The result is that hv_undef, which calls mro_isa_changed_in before deleting everything, was updating the subclasses’ isa caches while its own @ISA was still visible.
* Make delete $package::{ISA} workFather Chrysostomos2010-11-131-3/+7
|
* Fix memory leaks in mro_package_movedFather Chrysostomos2010-11-101-1/+1
| | | | | | | | | | | | This commit adds a new HV_FETCH_EMPTY_HE flag for hv_common. It is to be used in conjunction with HV_FETCH_LVALUE. It just stops the newly- created HE from having a new undef scalar assigned to it. This allows code to call hv_common just once instead of an hv_exists/ hv_store pair. It was such a double hv_common call that I was trying to avoid with HV_FETCH_LVALUE, without realising that it was leaking.
* Add docs for hv_ename_*Father Chrysostomos2010-10-291-0/+24
|
* Switch the core MRO code over to HvENAMEFather Chrysostomos2010-10-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | This has the side-effect of fixing these one-liners: $ perl5.13.5 -le' my $glob = \*foo::ISA; delete $::{"foo::"}; *$glob = *a' Bus error $ perl5.13.5 -le' my $glob = \*foo::ISA; delete $::{"foo::"}; *$glob = []' Bus error $ perl5.13.6 -le'sub baz; my $glob = \*foo::bar; delete $::{"foo::"}; *$glob = *baz;' Bus error $ perl5.13.6 -le'sub foo::bar; my $glob = \*foo::bar; delete $::{"foo::"}; *$glob = *baz;' Bus error In the first two cases the crash was inadvertently fixed (isn’t it nice when that happens?) in 5.13.6 (by 6f86b615fa7), but there was still a fatal error: Can't call mro_isa_changed_in() on anonymous symbol table at -e line 1. Because sv_clear calls ->DESTROY, if an object’s stash has been detached from the symbol table, mro_get_linear_isa can be called on a hash with no HvENAME. So HvNAME is used as a fallback for those cases.
* In S_hv_delete_common, call mro_package_moved after the deletionFather Chrysostomos2010-10-291-9/+33
|
* hv_ename_delete should not delete the HvNAMEFather Chrysostomos2010-10-291-2/+4
| | | | | | | | | | | | | | | This is something that 78b79c7758 missed. When xhv_name is a HEK *, it is both the regular name and the effect- ive name at the same time. Only when xhv_name_count is negative is the regular name not also the effective name. hv_ename_delete needs to take the HEK that xhv_name points to and put it in a new HEK * array in xhv_name. This array will just have one element. When xhv_name_count is negative, effective names start with the second element. So we set xhv_name_count to -1 so there isn’t one.
* Renaming of stashes should not be visible from PerlFather Chrysostomos2010-10-271-28/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | Change 35759254 made stashes get renamed when moved around. This had an unintended consequence: Typeglobs, ref() return values, stringifi- cation of blessed references and __PACKAGE__ are all affected by this. This commit makes a new distinction between stashes’ names and effect- ive names. Stash names are now unaffected when the stashes move around. Only the effective names are affected. (The apparent presence of any puns in the previous sentence is purely incidental and most likely the result of the reader’s inferential propensity.) To this end a new HvENAME_get macro is introduced, returning the first effective name (what HvNAME_get was returning). (Only one effective name needs to be in effect at a time.) hv_add_name and hv_delete_name have been renamed hv_add_ename and hv_delete_ename. hv_name_set is modified to leave the effective names in place unless the name is being set to NULL. These names are now stored in HvAUX as follows: When xhv_name_count is 0, xhv_name is a HEK pointer, containing the name which is also the effective name. When xhv_name_count is not zero, then xhv_name is a pointer to an array of HEK pointers. If xhv_name_count is positive, the first HEK is the name *and* one of the effective names. When xhv_name_count is negative, the first HEK is the name and subsequent HEKs are the effective names.
* Fix @ISA recursion during global destructionFather Chrysostomos2010-10-251-0/+1
| | | | | | | | | | | | | | | | | | | | | With -DDEBUGGING and make test (not make test_harness): Failed 3 tests out of 1889, 99.84% okay. mro/basic.t mro/recursion_c3.t mro/recursion_dfs.t See <http://www.nntp.perl.org/group/perl.perl5.porters/2010/10/msg165311.html>. This was broken by change 35759254, which made S_hv_delete_common call mro_package_moved when the G_DISCARD flag was passed. It used to be skipped, which was a mistake. This commit simply skips mro_package_moved when $::{"main::"} is deleted. It was buggy anyway (main::E being passed to recursive calls, instead of E), and should only happen at global destruction. (If $::{"main::"} is deleted at run-time, it stop Perl from being func- tional, so no one should be doing that.)
* Rename stashes when they move aroundFather Chrysostomos2010-10-241-13/+17
| | | | | | | | | | | | | | | | | | | | | | This is yet another patch in preparation for [perl #75176] (I keep saying that.). It uses the recently-added functions hv_name_add and hv_name_delete, to add and remove names when mro_package_moved is called. mro_package_moved’s calling convention needed to change to make this work, which is the bulk of the patch. Code that was calling mro_package_moved was also doing it sometimes when it was unnecessary. If the stash being assigned over had no name, then there was no possibiiity of its being in the symbol table. This probably fixes [perl #77358] (isa warnings), though I have not tested that yet. One user-visible change this introduces is that a detached glob whose stash loses its name will no longer stringify the same way (a bit like a glob that loses its stash pointer; except that it becomes *__ANON__::foo instead of "").
* Memory-management macros evaluate their arguments multiple timesFather Chrysostomos2010-10-241-2/+4
|
* Perl_hv_name_add needs to set xhv_name_count in one other place.Father Chrysostomos2010-10-231-1/+1
| | | | | Perl_hv_name_add was not setting the name count when upgrading a HEK* to an array of HEK*s.
* Add functions for adding and deleting stash namesFather Chrysostomos2010-10-221-0/+88
|
* [perl #78488] Bleadperl 304474c3 breaks GFUJI/Test-LeakTrace-0.13.tar.gzFather Chrysostomos2010-10-211-0/+1
| | | | | | | | | | | | | | | | This commit restores an SvREFCNT_dec that was inadvertently removed. c8bbf67 removed the SvREFCNT_dec(HeVAL(entry)), adding SvREFCNT_dec(old_val) instead. 304474c3 reverted that block, but failed to restore the SvREFCNT_dec(HeVAL(entry)). The result was that the %INC entry created by do "file" was leaking. (Y’know, giving out commit bits to just *anyone* who comes along with a few patches seems dangerous. Has anybody been looking at what I’m doing?)
* Avoid using #ifdef inside a function call that may itself actually be a macro.Nicholas Clark2010-10-211-2/+6
| | | | A tweak to 20439bc77dfeec46. Hopefully this fixes the build on Win32.
* Allow stashes to have multiple namesFather Chrysostomos2010-10-211-3/+24
| | | | | | | | | | | | | | | | | | This commits modifies the HvAUX structure as follows: A new field is added, named xhv_name_count, indicating the number of names. If it is zero (the default and most common case), then xhv_name is a HEK * as usual. If it is non-zero, then xhv_name actually holds a pointer to an array of HEK*s, the first being the default or ‘canonical’ name. This code is a little repetitious, but more refactorings are to come, so it is too soon to turn these repetitions into macros. This is yet another commit in preparation for fixing [perl #75176]. Basically, whenever a stash is deleted from its containing stash, if it has an alias elsewhere, it needs to assume the new name (of that alias; so it needs to know its other names already) and update isarev entries. Forthcoming commits will do that.
* full API for cop hint hashesZefram2010-10-211-186/+285
| | | | | | | | | | | | | Expose cop hint hashes as a type COPHH, with a cophh_* API which is a macro layer over the refcounted_he_* API. The documentation for cophh_* describes purely API-visible behaviour, whereas the refcounted_he_* documentation describes the functions mainly in terms of the implementation. Revise the cop_hints_* API, using the flags parameter consistently and reimplementing in terms of cophh_*. Use the cophh_* and cop_hints_* functions consistently where appropriate. [Modified by the committer to update two calls to Perl_refcounted_he_fetch recently added to newPMOP.]
* Document that av_delete and hv_delete make their return values mortal.Chip Salzenberg2010-10-141-8/+9
|
* Reset isa caches on nonexistent substashes when stash trees are movedFather Chrysostomos2010-10-121-1/+2
| | | | | | | | | | | | | | | | | This fixes the problem of isa cache linearisations’ and method caches’ not being reset on nonexistent packages when they are replaced with real packages as a result of parent stashes’ being moved. This can happen in cases like this: @left::ISA = 'outer::inner'; @right::ISA = 'clone::inner'; {package outer::inner} *clone:: = \%outer::; print "ok 1", "\n" if left->isa("clone::inner"); print "ok 2", "\n" if right->isa("outer::inner"); This changes mro_package_moved’s parameter list as documented in the diff for mro.c. See also the new comments in that function.
* Remove code added by c8bbf675 that turns out to be unnecessaryFather Chrysostomos2010-10-091-25/+0
|
* Reset isa on stash manipulationFather Chrysostomos2010-10-091-1/+37
| | | | | | | | | | | | This only applies to glob-to-glob assignments and deletions of stash elements. Other types of stash manipulation are dealt with by subse- quent patches. It adds mro_package_moved, a private function that iterates through subpackages, calling mro_isa_changed_in on each. This is related to [perl #75176], but is not the same bug. It simply got in the way of fixing [perl #75176].
* systematically provide pv/pvn/pvs/sv quartetsZefram2010-09-281-0/+5
| | | | | Anywhere an API function takes a string in pvn form, ensure that there are corresponding pv, pvs, and sv APIs.
* Silence compiler warningsSteve Hay2010-09-181-1/+1
|
* add hv_copy_hints_hv and save_hints to the APIZefram2010-09-161-2/+12
|
* fix hv.c API doc nits.David Mitchell2010-09-121-3/+3
| | | | | In prehistoric times the first arg to many hash functions was called tb rather than hv, and this was still reflected in some API notes.
* Remove offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size.Nicholas Clark2010-09-081-14/+2
| | | | | | | | | | | | | | | | | | These provided a non-public API for the hash and array code to donate free memory direct to the SV head allocation routines, instead of returning it to the malloc system with free(). I assume that on some older mallocs this could offer significant benefits. However, my benchmarking on a modern malloc couldn't detect any significant effect (positive or negative) on removing the code. Its (continued) presence, however, has downsides a: slightly more code complexity b: slightly larger interpreter structure c: in the steady state, if net creation of SVs is zero, 1 chunk of allocated but unused memory will exist (per thread) So I think it best to remove it.
* API functions for accessing the runtime hinthash.Ben Morrow2010-09-071-0/+51
| | | | | | | Add hinthash_fetch(sv|pv[ns]) as a replacement for refcounted_he_fetch, which is not API (and should not be). Also add caller_cx, as the correct XS equivalent to caller(). Lots of modules seem to have copies of this, so a proper API function will be more maintainable in future.
* Change the first argument of Perl_fetch_cop_label() to COP *Nicholas Clark2010-09-021-2/+5
| | | | | | | | | | From a suggestion from Ben Morrow. The first argument used to be struct refcounted_he *, which exposed an implementation detail - that the COP's labels are (now) stored in this way. Google Code Search and an unpacked CPAN both fail to find any users of this API, so the impact should be minimal.
* Refactor Perl_store_cop_label() to avoid exposing struct refcounted_he *.Nicholas Clark2010-09-011-7/+11
| | | | | | | Instead pass in a COP, as suggested by Ben Morrow. Also add length and flags parameters, and remove the comment suggesting this change. The underlying storage mechanism can honour length and UTF8/not, so there is no harm in exposing this one level higher.
* Expose more_bodies(), and use it to replace S_more_he().Nicholas Clark2010-08-201-19/+1
| | | | | | | Convert get_arena() to be static, as now its only user is Perl_more_bodies(). Perl_get_arena() was not in the public API, and neither Google codesearch nor an upacked CPAN show anything to be using it.
* clarify when HV backref is in magicDavid Mitchell2010-08-011-2/+4
| | | | | Fix up the comments in and above some functions to clarify that backref bagic for hVs may sometimes be moved back to HvAUX.
* optimise single backreferencesDavid Mitchell2010-08-011-10/+19
| | | | | | | | | | | Rather than creating an AV and pushing the backref onto it, store a single backref directly in the mg_obj or xhv_backreferences slot. If the backref is an AV, then we skip this optimisation (although I don't think at the moment, that an AV would ever be pointed to by some backref magic). So the test of whether the optimisation is is in effect is whether the thing in the slot is an AV or not.
* expand the xhv_backreferences code notesDavid Mitchell2010-07-291-7/+15
| | | | (so that I don't get so confused when I revisit this code in 5 years time)
View Lorry Controller Status