Hash Randomisation

       Mainly due to security reasons, the "random ordering" of
       hashes has been made even more random.  Previously while
       the order of hash elements from keys(), values(), and
       each() was essentially random, it was still repeatable.
       Now, however, the order varies between different runs of
       Perl.

       Perl has never guaranteed any ordering of the hash keys,
       and the ordering has already changed several times during
       the lifetime of Perl 5.  Also, the ordering of hash keys
       has always been, and continues to be, affected by the
       insertion order.

       The added randomness may affect applications.

       One possible scenario is when output of an application has
       included hash data.  For example, if you have used the
       Data::Dumper module to dump data into different files, and
       then compared the files to see whether the data has
       changed, now you will have false positives since the order
       in which hashes are dumped will vary.  In general the cure
       is to sort the keys (or the values); in particular for
       Data::Dumper to use the "Sortkeys" option.  If some par­
       ticular order is really important, use tied hashes: for
       example the Tie::IxHash module which by default preserves
       the order in which the hash elements were added.

       More subtle problem is reliance on the order of "global
       destruction".  That is what happens at the end of execu­
       tion: Perl destroys all data structures, including user
       data.  If your destructors (the DESTROY subroutines) have
       assumed any particular ordering to the global destruction,
       there might be problems ahead.  For example, in a destruc­
       tor of one object you cannot assume that objects of any
       other class are still available, unless you hold a refer­
       ence to them.  If the environment variable
       PERL_DESTRUCT_LEVEL is set to a non-zero value, or if Perl
       is exiting a spawned thread, it will also destruct the
       ordinary references and the symbol tables that are no
       longer in use.  You can't call a class method or an ordi­
       nary function on a class that has been collected that way.

       The hash randomisation is certain to reveal hidden assump­
       tions about some particular ordering of hash elements, and
       outright bugs: it revealed a few bugs in the Perl core and
       core modules.

       To disable the hash randomisation in runtime, set the
       environment variable PERL_HASH_SEED to 0 (zero) before
       running Perl (for more information see "PERL_HASH_SEED" in
       perlrun), or to disable the feature completely in compile
       time, compile with "-DNO_HASH_SEED" (see INSTALL).

       See "Algorithmic Complexity Attacks" in perlsec for the
       original rationale behind this change.