summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Move utility macros to their own fileYves Orton2017-04-233-82/+83
| | | | | | so that hv_func is left with only logic relating to selecting and configuring the hash function we use, not the macros our hash functions use.
* Add new hashing and "hash with state" infrastructureYves Orton2017-04-2310-281/+2642
| | | | | | | | | | | | | | | | | | | | | This adds support for three new hash functions: StadtX, Zaphod32 and SBOX, and reworks some of our hash internals infrastructure to do so. SBOX is special in that it is designed to be used in conjuction with any other hash function for hashing short strings very efficiently and very securely. It features compile time options on how much memory and startup time are traded off to control the length of keys that SBOX hashes. This also adds support for caching the hash values of single byte characters which can be used in conjuction with any other hash, including SBOX, although SBOX itself is as fast as the lookup cache, so typically you wouldnt use both at the same time. This also *removes* support for Jenkins One-At-A-Time. It has served us well, but it's day is done. This patch adds three new files: zaphod32_hash.h, stadtx_hash.h, sbox32_hash.h
* Tweak our hash bucket splitting rulesYves Orton2017-04-236-25/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch we resized hashes when after inserting a key the load factor of the hash reached 1 (load factor= keys / buckets). This patch makes two subtle changes to this logic: 1. We split only after inserting a key into an utilized bucket, 2. and the maximum load factor exceeds 0.667 The intent and effect of this change is to increase our hash tables efficiency. Reducing the maximum load factor 0.667 means that we should have much less keys in collision overall, at the cost of some unutilized space (2/3rds was chosen as it is easier to calculate than 0.7). On the other hand, only splitting after a collision means in theory that we execute the "final split" less often. Additionally, insertin a key into an unused bucket increases the efficiency of the hash, without changing the worst case.[1] In other words without increasing collisions we use the space in our hashes more efficiently. A side effect of this hash is that the size of a hash is more sensitive to key insert order. A set of keys with some collisions might be one size if those collisions were encountered early, or another if they were encountered later. Assuming random distribution of hash values about 50% of hashes should be smaller than they would be without this rule. The two changes complement each other, as changing the maximum load factor decreases the chance of a collision, but changing to only split after a collision means that we won't waste as much of that space we might. [1] Since I personally didnt find this obvious at first here is my explanation: The old behavior was that we doubled the number of buckets when the number of keys in the hash matched that of buckets. So on inserting the Kth key into a K bucket hash, we would double the number of buckets. Thus the worse case prior to this patch was a hash containing K-1 keys which all hash into a single bucket, and the post split worst case behavior would be having K items in a single bucket of a hash with 2*K buckets total. The new behavior says that we double the size of the hash once inserting an item into an occupied bucket and after doing so we exceeed the maximum load factor (leave aside the change in maximum load factor in this patch). If we insert into an occupied bucket (including the worse case bucket) then we trigger a key split, and we have exactly the same cases as before. If we insert into an empty bucket then we now have a worst case of K-1 items in one bucket, and 1 item in another, in a hash with K buckets, thus the worst case has not changed.
* use a specific define for 64 bit hashingYves Orton2017-04-231-8/+12
|
* Link to epigraphSawyer X2017-04-211-1/+1
|
* Merge branch 'blead' of ssh://perl5.git.perl.org/perl into bleadSawyer X2017-04-211-1/+1
|\
| * Corelist MorelistChris 'BinGOs' Williams2017-04-201-1/+1
| |
* | Bump version: 5.25.12 -> 5.26.0Sawyer X2017-04-2128-203/+203
| |
* | Bump Module::CoreList versionSawyer X2017-04-214-3/+33
| |
* | Fix empty link problemSawyer X2017-04-2012-56/+472
| |
* | Tick offSawyer X2017-04-201-1/+1
| |
* | Add epigraph, minus the linkSawyer X2017-04-201-0/+12
|/
* Merge branch 'release-5.25.12' into bleadSawyer X2017-04-204-317/+51
|\
| * Remove refs to bare ?RE? in podsv5.25.12Karl Williamson2017-04-203-9/+5
| |
| * add new release to perlhistSawyer X2017-04-201-0/+1
| |
| * Finalizing perldeltaSawyer X2017-04-201-22/+14
| |
| * Fix perldelta and perldiagSawyer X2017-04-202-2/+2
| |
| * Update Module::CoreList for 5.25.12Sawyer X2017-04-201-2/+11
| |
| * Preparing perldeltaSawyer X2017-04-202-297/+26
| |
| * Document 1c99110 in the right placeSawyer X2017-04-202-5/+8
| |
* | Remove refs to bare ?RE? in podsKarl Williamson2017-04-203-9/+5
|/
* Regenerate opcodes (regen/opcode.pl)Sawyer X2017-04-191-1/+1
|
* Regen uconfig.shSawyer X2017-04-191-1/+1
|
* Set Module::CoreList back to 5.25.12Sawyer X2017-04-193-6/+6
|
* Mark as unstableSawyer X2017-04-191-1/+1
|
* Version debump: 5.26.0 -> 5.25.12Sawyer X2017-04-1927-200/+200
|
* Another dev release...Sawyer X2017-04-191-1/+3
|
* [MERGE] fix require's croak messageDavid Mitchell2017-04-182-31/+195
|\ | | | | | | | | | | | | | | | | | | | | RT #131098 This branch fixes two issues with the message produced when require croaks. First it mentioned @INC even when @INC wasn't scanned, and second it emitted the "you may need to install Foo::Bar module" hint even when the failed-to-load pathname wasn't reverse-mappable to a module name.
| * emit require module name err hint only when validDavid Mitchell2017-04-182-16/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RT #131098 The helpful "you may need to install" hint which 'require' sometimes includes in its error message these days (split across multiple lines for clarity): $ perl -e'require Foo::Bar' Can't locate Foo/Bar.pm in @INC (you may need to install the Foo::Bar module) (@INC contains: ... ) at ... is a bit over-enthusiastic when the pathname hasn't actually been derived from a module name: $ perl -e'require "Foo.+/%#Bar.pm"' Can't locate Foo.+%#Bar.pm in @INC (you may need to install the Foo.+::%#Bar module) (@INC contains: ... ) at ... This commit changes things so that the hint message is only emitted if the reverse-mapped module name is legal as a bareword: $ perl -e'require "Foo.+/%#Bar.pm"' Can't locate Foo.+%#Bar.pm in @INC (@INC contains: ... ) at ...
| * require die msg: only mention @INC if usedDavid Mitchell2017-04-182-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RT #131098 5.8.0 introduced a change which as an inadvertent side-effect caused this @INC-related require croak message: Can't locate foo in @INC (@INC contains: ...) at ... to be emitted even when foo is a non-searchable pathname (like /foo or ./foo) and @INC isn't used. This commit reverts the error message in these cases to be the simple Can't locate foo at ...
| * S_require_file() : simplify an else if blockDavid Mitchell2017-04-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | change if (...) { ... } else { if (...) { ... } } to if (...) { ... } else if (...) { ... } Should make no functional difference
| * better comment require() source.David Mitchell2017-04-181-11/+42
|/ | | | | Add code more comments to S_require_file() and its helpder functions to better understand what's going on.
* add PERL_UTIL_H_ to util.h, not util.hDavid Mitchell2017-04-182-6/+6
| | | | | | | With v5.25.11-59-g7335cb8 I added an include guard. PERL_UTIL_H_, but added it to util.c rather than util.h. I am not a smart man....
* Workaround for GNU Autoconf unescaped left braceKarl Williamson2017-04-172-2/+23
| | | | | | | | | | | | | | | | | | | | | See [perl #130497] GNU Autoconf depends on Perl, and will not work on Blead (and the forthcoming Perl 5.26), due to a single unescaped '{', that has previously been deprecated and is now fatal. A patch for it has been in the Autoconf repository since early 2013, but there has not been a release since before then. Because this is depended on by so much code, and because it is simpler than trying to revert to making the fatality merely deprecated, this patch simply changes perl to not die when compiled with the exact pattern that trips up Autoconf. Thus Autoconf can continue to work, but any other patterns that use the now illegal construct will continue to die. If other code uses the exact pattern, they too will not die, but the deprecation message continues to get raised. The use of the left brace in this particular pattern is not one where we envision using the construct to mean something else, so a deprecation is suitable for the foreseeable future.
* Net-Ping udp not allowed in AIX or IRIX, either.Jarkko Hietaniemi2017-04-171-1/+1
|
* Update CPAN.pm to ANDK/CPAN-2.18-TRIAL.tar.gzDavid Mitchell2017-04-164-5/+10
| | | | | | | | | | | RT #131141 CPAN-2.17-TRIAL tried to narrow the scope to the phases prepare, make, and test, but after some testing evidence took shape that PERL_USE_UNSAFE_INC=1 is also needed for the install phase. 2.18 provides this change. The second issue fixed in 2.18 addresses RT #120781, an ugly bug with a trivial fix.
* add include guard to util.hDavid Mitchell2017-04-161-0/+6
| | | | | | see RT #131110 for the bikeshedding on what name to use. Based on an original patch by Jim Schneider
* threads::shared: alloc arenas with correct contextDavid Mitchell2017-04-143-5/+29
| | | | | | | | | | RT #131124 In a couple of places in shared.xs, it calls sv_newmortal() with a perl context different from that currently set by PERL_SET_CONTEXT(). If sv_newmortal() happens to trigger the malloc of a new SV HEAD arena, then under PERL_TRACK_MEMPOOL, this will cause panics when the arena is freed or realloced.
* fix perldiag entry for do '.' warningDavid Mitchell2017-04-131-1/+1
| | | | Its an enabled-by-default deprecation warning
* more tweaks to 'do's podDavid Mitchell2017-04-131-7/+11
| | | | Make it clear that both ./ and ../ are special-cased.
* perlunicode: Update text about malformed UTF-8Karl Williamson2017-04-111-11/+19
|
* PATCH: [perl #130801] perlapi: Clarify SvIV/SvUV/SvNV behaviorPali2017-04-111-18/+33
| | | | [The committer made a few changes for improved readability]
* perlunicode: Add linkKarl Williamson2017-04-091-1/+2
|
* PATCH: [perl #121292] wrong perlunicode BOM claimsKarl Williamson2017-04-081-6/+8
| | | | | A BOM at the beginning of a UTF-8 file is ignored, and doesn't otherwise do anything.
* Spelling corrections only.James E Keenan2017-04-071-2/+2
|
* [MERGE] make tests run without '.' in @INCDavid Mitchell2017-04-0761-64/+147
|\ | | | | | | | | | | Update TestInuit.pm etc so that tests are no longer invoked with '.' in @INC. Then fix up all the tests that break because of this. Then fix up some bad usage of 'do' that's not detected by tests.
| * Safe.pm: document rdo()'s usage of @INCDavid Mitchell2017-04-071-1/+4
| |
| * fix and test execution of non-empty .bs filesDavid Mitchell2017-04-076-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the build of XS modules, an empty Foo.bs file is normally created for each Foo.so file. If a Foo_BS file is present, instead this triggers the auto-generatation of a .bs file which may have executable perl content. However, nothing in core currently generates a non-empty .bs file. So add a test that this mechanism works, and fix up the three dynamic lib loaders which implement the 'do $bs if -s $bs' mechanism to not rely on the process having '.' present in @INC. As it happens this already works currently, because the name of the .bs file to load will usually be something like ../../lib/auto/Foo/Foo.bs and the presence of the leading '..' causes 'do' to load the file directly rather than via @INC. But locally fix up @INC anyway, in case '../' isn't always the case.
| * dist/Unicode-Normalize/Makefile.PL: fix 'do'David Mitchell2017-04-071-1/+1
| | | | | | | | | | | | It 'do's a file in the current directory, which fails without '.' in @INC. This doesn't matter in core at the moment, but CPAN releases should be fixed.
| * fix cases where 'do file' should be 'do ./file'.James E Keenan2017-04-073-4/+4
| | | | | | | | | | | | These are some cases which weren't picked up by the test suite [ This is a subset of a set of fixes originally submitted by James as 2 commits - DAPM]
View Lorry Controller Status