summaryrefslogtreecommitdiff
path: root/hv.h
Commit message (Collapse)AuthorAgeFilesLines
* Split the XPVHV body into two variants "normal" and "with aux"Nicholas Clark2021-10-111-1/+8
| | | | | | | | Default to the smaller body, and switch to the larger body if we need to allocate a C<struct xpvhv_aux> (eg need an iterator). This restores the previous small size optimisation for hashes used as objects.
* Delete the do_aux code from S_hsplit()Nicholas Clark2021-10-111-12/+0
| | | | | | | | This existed to handle automatically allocating an "aux" structure for larger hashes, to save a (large) reallocation if they needed to be iterated. Now that we no longer store the aux structure in the main hash array, we don't need to take this precaution.
* Inline the xhv_aux struct in the main hash bodyNicholas Clark2021-10-111-1/+2
| | | | | For now, memory for this structure is always allocated, even though it isn't always flagged as being present.
* Delete the macro XHvTOTALKEYS() which is unused and not in the API.Nicholas Clark2021-08-261-4/+1
| | | | | | | | | | | | | | | | XHvTOTALKEYS() was added in Dec 2001 as part of commit 8aacddc1ea3837f8: Tidied version of Jeffrey Friedl's <jfriedl@yahoo.com> restricted hashes - added delete of READONLY value inhibit & test for same - re-tabbed It's not part of the API, and not used by any code on CPAN. The last (and only) direct use was in Perl_hv_clear_placeholders(), and that was converted to HvTOTALKEYS() in May 2005 as part of commit 5d88ecd7e75b7174: Various HvPLACEHOLDERS() that should be HvPLACEHOLDERS_get() Hence "inline" the macro XHvTOTALKEYS() into the macro HvTOTALKEYS(), eliminating the only use of XHvTOTALKEYS().
* Convert code in mro_core.c to use hv_*hek() APIs where possible.Nicholas Clark2021-07-261-0/+3
| | | | | | | | Add a macro hv_existshek() to implement exists. The HEK-based macros are more efficient wrappers of hv_common() than the string/length/flags macros because they also pass in the pre-computed hash value (from the HEK). This avoids hv_common() needing to recalculate it.
* Make REFCOUNTED_HE_EXISTS available outside of coreLeon Timmermans2021-03-151-3/+1
| | | | This is needed to be able to define cophh_exists functions
* style: Detabify indentation of the C code maintained by the core.Michael G. Schwern2021-01-171-54/+54
| | | | | | | | | | | This just detabifies to get rid of the mixed tab/space indentation. Applying consistent indentation and dealing with other tabs are another issue. Done with `expand -i`. * vutil.* left alone, it's part of version. * Left regen managed files alone for now.
* autodoc.pl: Specify scn for single-purpose filesKarl Williamson2020-11-061-2/+0
| | | | | | | | Many of the files in perl are for one thing only, and hence their embedded documentation will be for that one thing. By creating a hash here of them, those files don't have to worry about what section that documentation goes under, and so it can be completely changed without affecting them.
* Fix return type in pod for HvNAMELEN_getKarl Williamson2020-09-281-1/+1
| | | | 37738dd69b1 set it incorrectly
* Note for Devel::PPPort HvNAME_get, HvNAMELEN_getKarl Williamson2020-09-051-0/+4
|
* Reorganize perlapiKarl Williamson2020-09-041-5/+1
| | | | | This uses a new organization of sections that I came up with. I asked for comments on p5p, but there were none.
* Change pod for macros that require "literal strings"Karl Williamson2019-09-021-2/+2
| | | | | Now that Devel::PPPort has the ability to handle these, we can loosen the syntax for clarity.
* Document HvFILLKarl Williamson2019-09-021-0/+10
|
* Fix apidoc macro entriesKarl Williamson2019-06-251-2/+2
| | | | | | | | | | This makes various fixes to the text that is used to generate the documentation. The dominant change is to add the 'n' flag to indicate that the macro takes no arguments. A couple should have been marked with a D (for deprecated) flag, and a couple were missing parameters, and a couple were missing return values. These were spotted by using Devel::PPPort on them.
* better document macros taking literal stringsZefram2017-11-121-4/+4
| | | | | | | | | | When giving a function-style prototype for a macro taking a literal string parameter, put a string literal in place of a type for that parameter. This goofy appearance makes it obvious that this isn't really a function, and clues the reader in that the parameter can't actually be an arbitrary expression of the right type. Also change the nonsensical "NUL-terminated literal string" to "literal string" to describe these parameters. Fixes [perl #116286].
* HvTOTALKEYS() takes a HV* as argumentSteffen Mueller2017-02-031-1/+1
| | | | | | | Incidentally, it currently works on SV *'s as well because there's an explicit cast after an SvANY. Let's not rely on that. This commit also removes a pointless const in a cast. Again. It takes an HV * as argument. Let's only change that if we have a strong reason to.
* Use cBOOL() instead of ? TRUE : FALSEDagfinn Ilmari Mannsåker2017-01-251-4/+2
| | | | Except under cpan/ and dist/
* fix hv.h build breakageDavid Mitchell2016-11-031-1/+0
| | | | The previous commit had a double closing comment (*/)
* add a comment about the properties of struct hekYves Orton2016-11-031-4/+10
|
* Revert "hv.h: rework HEK_FLAGS to a proper member in struct hek"Tony Cook2016-11-031-2/+3
| | | | | | | | This reverts commit d3148f758506efd28325dfd8e1b698385133f0cd. SV keys are stored as pointers in the key_key, on platforms with alignment requirements (such as PA-RISC) this resulted in bus errors early in the build.
* hv.h: rework HEK_FLAGS to a proper member in struct hekTodd Rinaldo2016-10-241-3/+2
| | | | | | | | | | | | | | | | | | | | | Move the store of HEK_FLAGS off the end of the allocated hek_key into the hek struct, simplifying access and providing clarity to the code. What is not clear is why Nicholas or perhaps Jarkko did not do this themselves. We use similar tricks elsewhere, so perhaps it was just continuing a tradition... One thought is that we often have do strcmp/memeq on these strings, and having their start be aligned might improve performance, wheras this patch changes them to be unaligned. If so perhaps we should just make flags a U32 and let the HEK's be larger. They are shared in PL_strtab, and are probably often sitting in malloc blocks that are sufficiently large enough that making them bigger would make no practical difference. (All of this is worth checking.) [with edits by Yves Orton]
* handy.h, hv.h: fixup hash s suffix macro definitions, move to hv.hYves Orton2016-10-191-0/+20
| | | | | | | | | | | | | For some reason s suffix macro definitions intended for handling constant string arguments were put into handy.h and not into hv.h. I think this is wrong, especially as the macro defintions have "drifted" and are not properly defined in terms the right base macros. Also we want to have such wrappers for the main hash functions, so move them all to hv.h, recode them properly in terms of the right base macros, and add support for the missing functions.
* Change scalar(%hash) to be the same as 0+keys(%hash)Yves Orton2016-06-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This subject has a long history see [perl #114576] for more discussion. https://rt.perl.org/Public/Bug/Display.html?id=114576 There are a variety of reasons we want to change the return signature of scalar(%hash). One is that it leaks implementation details about our associative array structure. Another is that it requires us to keep track of the used buckets in the hash, which we use for no other purpose but for scalar(%hash). Another is that it is just odd. Almost nothing needs to know these values. Perhaps debugging, but we have several much better functions for introspecting the internals of a hash. By changing the return signature we can remove all the logic related to maintaining and updating xhv_fill_lazy. This should make hot code paths a little faster, and maybe save some memory for traversed hashes. In order to provide some form of backwards compatibility we adds three new functions to the Hash::Util namespace: bucket_ratio(), num_buckets() and used_buckets(). These functions are actually implemented in universal.c, and thus always available even if Hash::Util is not loaded. This simplifies testing. At the same time Hash::Util contains backwards compatible code so that the new functions are available from it should they be needed in older perls. There are many tests in t/op/hash.t that are more or less obsolete after this patch as they test that xhv_fill_lazy is correctly set in various situations. However since we have a backwards compat layer we can just switch them to use bucket_ratio(%hash) instead of scalar(%hash) and keep the tests, just in case they are actually testing something not tested elsewhere.
* minor comment improvements in hv.h and scope.hDaniel Dragan2016-02-161-1/+2
| | | | | -perl doesn't use malloc, it uses Newx (per interp memory) -say what the return type is of SSNEW
* [perl #126410] keep the DESTROY cache in mro_metaTony Cook2016-02-081-0/+1
| | | | | | | | | | | | | We're already keeping destroy_gen there, so keep the CV there too. The previous implementation, introduced in 8c34e50d, kept the destroy method cache in the stash's stash, which broke B's SvSTASH method. Before that, the DESTROY method was cached in overload magic. A previous version of this patch didn't clear the destructor cache on a clone, which caused ext/XS-APItest/t/clone_with_stack.t to fail.
* perlapi: Clarify that a literal string must end in a NULKarl Williamson2016-02-031-4/+4
| | | | Some entries already had this. For those, it standardizes the text.
* perlapi use 'UTF-8' instead of variants of thatKarl Williamson2015-09-031-2/+2
|
* Various pods: Add C<> around many typed-as-is thingsKarl Williamson2015-09-031-1/+1
| | | | Removes 'the' in front of parameter names in some instances.
* perlapi, perlintern: Add L<> links to podKarl Williamson2015-09-031-2/+2
|
* 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.
* Change name of mro.cKarl Williamson2015-03-191-1/+1
| | | | | | | | | This is to prevent a conflict showing up on z/OS (os390) because this file's name is the same as one in /ext, and there are functions cross-referenced between them, and the loader on that platform can't deal with this. See http://nntp.perl.org/group/perl.perl5.porters/226612
* fix documentation of HeUTF8 return valueDavid Golden2014-04-041-1/+1
|
* hv.h: tweak comment about HvAUX preallocation for large hashesAaron Crane2014-03-201-1/+3
|
* Preallocate HvAUX() structures for large bucket arraysYves Orton2014-03-181-0/+10
| | | | | | | | | | | | The assumption is that the time/space tradeoff of not allocating the HvAUX() structure goes away for a large bucket array where the size of the allocated buffer is much larger than the nonallocated HvAUX() "extension". This should make keys() and each() on larger hashes faster, but still preserve the essence of the original space conservation, where the assumption is a lot of small hash based objects which will never be traversed.
* speed up (non)overloaded derefsDavid Mitchell2014-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a class that has some minimal overloading added - e.g. to give pretty stringification of objects - but which *doesn't* overload dereference methods such as '@[]'. '%[]' etc. In this case, simple dereferencing, such as $obj->[0] or $obj->{foo} becomes much slower than if the object was blessed into a non-overloaded class. This is because every time a dereferencing is performed in pp_rv2av for example, the "normal" code path has to go through the full checking of: * is the stash into which the referent is blessed overloaded? If so, * retrieve the overload magic from the stash; * check whether the overload method cache has been invalidated and if so rebuild it; * check whether we are in the scope of 'no overloading', and if so is the current method disabled in this scope? * Is there a '@{}' or whatever (or 'nomethod') method in the cache? If not, then process the ref as normal. That's a lot of extra overhead to decide that an overloaded method doesn't in fact need to be called. This commit adds a new flag to the newish xhv_aux_flags field, HvAUXf_NO_DEREF, which signals that the overloading of this stash contains no deref (nor 'nomethod') overloaded methods. Thus a quick check for this flag in the common case allows us to short-circuit all the above checks except the first one. Before this commit, a simple $obj->[0] was about 40-50% slower if the class it was blessed into was overloaded (but didn't have deref methods); after the commit, the slowdown is 0-10%. (These timings are very approximate, given the vagaries of nano benchmarks.)
* gv_check(): use aux flag rather than IsCOWDavid Mitchell2014-02-281-0/+2
| | | | | | | | | | 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).
* add aux_flags field to HVs with aux structDavid Mitchell2014-02-281-0/+1
| | | | | | | | | | | | | Add an extra U32 general flags field to the xpvhv_aux struct (which is used on HVs such as stashes, that need extra fields). On 64-bit systems, this doesn't consume any extra space since there's already an odd number of I32/U32 fields. On 32-bit systems it will consume an extra 4 bytes. But of course only on those hashes that have the aux struct. As well as providing extra flags in the AUX case, it will also allow us to free up at least one general flag bit for HVs - see next commit.
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-9/+10
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* Make mro code pass precomputed hash valuesFather Chrysostomos2013-11-041-0/+10
| | | | | | | | where possible This involved adding hv_fetchhek and hv_storehek macros and changing S_mro_clean_isarev to accept a hash parameter and expect HVhek_UTF8 instead of SVf_UTF8.
* hv.h: missing macro parenthesesFather Chrysostomos2013-11-041-1/+1
| | | | Let’s defuse this time bomb before it causes problems.
* When deleting via hek, pass the computed hash valueFather Chrysostomos2013-10-281-0/+6
| | | | | | | In those cases where the hash key comes from a hek, we already have a computed hash value, so pass that to hv_common. The easiest way to accomplish this is to add a new macro.
* [perl #79074] make sure HeSVKEY_force() preserves UTF8ness (pvn)Tony Cook2013-09-161-1/+3
| | | | | | | | | | HeSVKEY_force() is only used in two places in core. In the first case, the key is always stored as a SV (when handling tie magic, since NEXTKEY can only return a SV) The second case is in B::HE, but I don't see a way to create a B::HE object from a hash.
* Move super cache into mro metaFather Chrysostomos2013-08-201-1/+1
| | | | | | | Iterated hashes shouldn’t have to allocate space for something specific to stashes, so move the SUPER method cache from the HvAUX struct (which all iterated hashes have) into the mro meta struct (which only stashes have).
* [perl #114864] Make UNIVERSAL::DESTROY changes invalidate cachesFather Chrysostomos2013-08-171-0/+1
| | | | | | | | | Commit 8c34e50d inadvertently caused DESTROY caches not to be reset when UNIVERSAL::DESTROY changes. Normally, a change to a method will cause mro_method_changed_in to be called on all subclasses, but mro.c cheats for UNIVERSAL and just does ++PL_sub_generation. So clearing the DESTROY cache explicitly in mro_method_changed_in is clearly not enough.
* Cache HvFILL() for larger hashes, and update on insertion/deletion.Nicholas Clark2013-05-291-1/+2
| | | | | | 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.)
* document and improve hash algorithm randomization related build optionsYves Orton2013-05-081-9/+13
| | | | | | Install was a copy of other material, made heavy reference to 5.8.x and and didnt really document what it should have. I reworked it to be more up to date.
* Make it possible to disable and control hash key traversal randomizationYves Orton2013-05-071-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for PERL_PERTURB_KEYS environment variable, which in turn allows one to control the level of randomization applied to keys() and friends. When PERL_PERTURB_KEYS is 0 we will not randomize key order at all. The chance that keys() changes due to an insert will be the same as in previous perls, basically only when the bucket size is changed. When PERL_PERTURB_KEYS is 1 we will randomize keys in a non repeatedable way. The chance that keys() changes due to an insert will be very high. This is the most secure and default mode. When PERL_PERTURB_KEYS is 2 we will randomize keys in a repeatedable way. Repititive runs of the same program should produce the same output every time. The chance that keys changes due to an insert will be very high. This patch also makes PERL_HASH_SEED imply a non-default PERL_PERTURB_KEYS setting. Setting PERL_HASH_SEED=0 (exactly one 0) implies PERL_PERTURB_KEYS=0 (hash key randomization disabled), settng PERL_HASH_SEED to any other value, implies PERL_PERTURB_KEYS=2 (deterministic/repeatable hash key randomization). Specifying PERL_PERTURB_KEYS explicitly to a different level overrides this behavior. Includes changes to allow one to compile out various aspects of the patch. One can compile such that PERL_PERTURB_KEYS is not respected, or can compile without hash key traversal randomization at all. Note that support for these modes is incomplete, and currently a few tests will fail. Also includes a new subroutine in Hash::Util::hash_traversal_mask() which can be used to ensure a given hash produces a predictable key order (assuming the same hash seed is in effect). This sub acts as a getter and a setter. NOTE - this patch lacks tests, but I lack tuits to get them done quickly, so I am pushing this with the hope that others can add them afterwards.
* eliminate the only internal uses of HvFILLYves Orton2013-03-271-0/+2
| | | | | | | | | | | | | | | | | The usages are as far as I know incorrect anyway. We resize the hash bucket array based on the number of keys it holds, not based on the number of buckets that are used, so this usage was wrong anyway. Another bug that this revealed is that the old code would allow HvMAX(hv) to fall to 0, even though every other part of the core expects it to have a minimum of 7 (meaning 8 buckets). As part of this we change the hard coded 7 to a defined constant PERL_HASH_DEFAULT_HvMAX. After this patch there remains one use of HvFILL in core, that used for scalar(%hash) which I plan to remove in a later patch.
* improve how Devel::Peek::Dump handles iterator informationYves Orton2013-03-241-0/+3
| | | | | | | | * If the hash is not OOK omit any iterator status information instead of showing -1/NULL * If the hash is OOK then add the RAND value from the iterator and if the LASTRAND is not the same show it too * Tweak tests to test the above.
* detect each() after insert and produce warnings when we doYves Orton2013-03-191-0/+2
| | | | | | | | | | | | | | | Inserting into a hash that is being traversed with each() has always produced undefined behavior. With hash traversal randomization this is more pronounced, and at the same time relatively easy to spot. At the cost of an extra U32 in the xpvhv_aux structure we can detect that the xhv_rand has changed and then produce a warning if it has. It was suggested on IRC that this should produce a fatal error, but I couldn't see a clean way to manage that with "strict", it was much easier to create a "severe" (internal) warning, which is enabled by default but suppressible with C<no warnings "internal";> if people /really/ wanted.