develooper Front page | perl.perl5.porters | Postings from January 2017

Re: Should we consider locked hashes a failed experiment?

Thread Previous | Thread Next
Steffen Mueller
January 28, 2017 18:45
Re: Should we consider locked hashes a failed experiment?
Message ID:
On 01/28/2017 03:31 PM, demerphq wrote:
> Steffen has started working on a patch series to make hashes
> pluggable. (Big big fricking A to him on that!) This is only going to
> be more complex if we support locking (does every hash implementation
> have to support locking? Does the hash api have to support
> "clear_placeholders"?

Since Yves is already pimping what I'm doing, let me add a tiny bit of 

In a nutshell, see the commit message for the first commit in 
smueller/hash_vtable (attached below for your convenience).

My expectations for this are essentially:
- That I'm enjoying myself, stealing a few minutes of spare time here 
and there. (Been too long since I hacked on anything of substance.)
- To try and see how viable this is.
- To find out what exactly this first stab will fail on.
- That I might run out of spare time at any moment.

Which is to say:
- I'm perfectly willing to cut corners and make some changes that I know 
won't be merged into blead as is.
- I'm anticipating that try #1 will fail, except in that it's for learning.

I also don't have any good bit of language design in mind on how to 
expose this to regular Perl users.

So, this all being said, I'm totally open to collaboration and feedback. 
If the feedback is constructive, but essentially boils down to "in order 
to get this into blead, you need to implement it in a completely 
different and much more complex/exhausting way", then please understand 
that I might not jump at it because I'm trying to prototype something 
rather than getting it perfect from day one. This is primarily because 
I'd rather have a working prototype by the time I run out of spare time 
instead of a 20% implementation that's promising. Hope y'all understand!

Best regards,

commit f5273c31fc75116e686a7151faeada96493fa72f
Author: Steffen Mueller <>
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 
     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 
     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.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About