In perl.git, the branch smueller/hash_vtable has been created
<http://perl5.git.perl.org/perl.git/commitdiff/e854d9268d27d3194e7079943a767c4d0eba4cab?hp=0000000000000000000000000000000000000000>
at e854d9268d27d3194e7079943a767c4d0eba4cab (commit)
- Log -----------------------------------------------------------------
commit e854d9268d27d3194e7079943a767c4d0eba4cab
Author: Steffen Mueller <[email protected]>
Date: Tue Jan 24 10:48:06 2017 +0100
Proof of principle hash vtables
This is a very partial implementation of having pluggable hashes by
(optionally) having magic-alike vtables which make all top level hash
operations pluggable.
At this point, this has all sorts of objectionable shortcuts. It also
means slowing down all operations by at least and extra compare+branch.
It also only does this for deletes right now because I'm just dabbling.
So in summary, this isn't much at all.
The reason why I'm playing with this is that if one were able to
specialize hash implementations (eg. perfect hashes or scanning small
lists for low-number-of-keys objects, having actual sets for huge
sets, having more compact "string only" (ie. no SV overhead) tables,
etc etc), I'd expect that one could gain a bunch.
Ultimately, this sort of thing is hindered by a great deal of things
such as the complete insanity of the hash API (way too many ways to do
things), the structure of the code (it's all shims to the same common
function - in an attempt to reduce code duplication), and the horror
that is MAGIC support. It's also decidedly hindered by my understanding
of the intricacies of the code base.
This doesn't solve the language design issue of how one would actually
make this accessible to Perl users. It'd be reasonably easy to have a
new keyword that takes an additional first parameter which indicates the
hash storage type (presumably as a constant string which can be
converted to a vtable at compile time using some kind of global lookup).
In terms of execution, this could generate either an OP that is similar
to pp_anonhash but has the type info on the stack, or it could literally
generate a pp_anonhash which abuses its op_targ as a way to store the
vtable pointer (PADOFFSET is an IV or UV which are big enough to hold a
pointer, but yuck.).
So I'm throwing this out there in case somebody (which includes my
future self) finds this intriguing enough to try to pursue further.
Right now, this commit includes a small change that redefines newHV to
ALWAYS assign a vtable (instead of defaulting to NULL, which falls
through to the normal hash implementation). It also ships a (partial)
vtable implementation which is meant to behave exactly the same way as
the normal implementation. This is to test that this whole scheme
actually work. As I was saying, right now in this commit, newHV is
hardwired to always set this "mock" vtable for testing.
-----------------------------------------------------------------------
--
Perl5 Master Repository
