In perl.git, the branch smueller/hash_vtable has been created
<http://perl5.git.perl.org/perl.git/commitdiff/c05f9c68ece9751cb440e9a72bff228b062da250?hp=0000000000000000000000000000000000000000>
at c05f9c68ece9751cb440e9a72bff228b062da250 (commit)
- Log -----------------------------------------------------------------
commit c05f9c68ece9751cb440e9a72bff228b062da250
Author: Steffen Mueller <[email protected]>
Date: Tue Feb 7 22:00:07 2017 +0100
Hash vtables: Remove done TODOs
M hv_vtbl.h
commit 624d6909c8695e32098b94868bba36357491be84
Author: Steffen Mueller <[email protected]>
Date: Tue Feb 7 21:55:44 2017 +0100
Hash vtables: wrap hv_iternext
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 32d392e76536d530ca9a5bf18edd8dac46f5bfbc
Author: Steffen Mueller <[email protected]>
Date: Tue Feb 7 17:29:48 2017 +0100
Hash vtables: Wrap hv_iterinit
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 18f319cb7b53376c724fc7bd00761bc86570b84d
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 17:28:27 2017 +0100
Hash vtables: Fix SAVEPPTR for stores
This leaves just the non-SV branch of the fetch hook which is buggy.
Seem comment in code. Fix entirely unobvious as of now.
M hv_vtbl.c
commit fa5d64005d9b637cff47d87d50b01f0037bf4111
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 17:07:32 2017 +0100
Hash vtables: Fix SAVEPPTR call for fetch_ent, note problem for fetch
M hv_vtbl.c
commit 21cb021adc81bbb30fa3f1f7f6f2affc76128831
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 16:35:30 2017 +0100
Hash vtables: Fix SAVEPPTR bug for deletes
M hv_vtbl.c
commit efeeafc377f7c8f550de7a65b2cd0f4d90e51811
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 16:25:34 2017 +0100
Hash vtables: Also fix SAVEPPTR calls for clear/undef/clone
M hv_vtbl.c
commit a76e8c9a84ea739b2ce467ae9a56bc953d685009
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 14:00:42 2017 +0100
Hash vtables: Fix savestack usage for exists
Man. these are going to be uncovering a bunch of bugs I missed. m(
M hv_vtbl.c
commit b7aebc7cce6471c71700b8fd801c5f6a7ac7715a
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 13:56:22 2017 +0100
Hash vtables: Sigh. Wrap newHVhv.
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 34cfcb7323007ea3117a96110300f46068f92673
Author: Steffen Mueller <[email protected]>
Date: Fri Feb 3 09:21:59 2017 +0100
Hash vtables: Sigh, vtables for key count access
This is ugly. Ugly. Ugly. Ugly.
This adds vtables for HvTOTALKEYS and friends.
First off, the distinction of HvTOTALKEYS and HvUSEDKEYS is a bit
dodgy/special-purpose for the placeholder logic. Which is annoying in
that we even have to deal with that corner case. Furthermore, everyone
and their kitchen sink seems to assume that HvTOTALKEYS is an lvalue. At
which point having that as a macro abstraction is a point almost defeated.
A mythical "HvTOTALKEYS_set" wouldn't make sense either since even
writing to such a thing would make little to no sense for other hash
implementations. Maybe the right thing to do is to have a
HvTOTALKEYS_set and a vtable entry that just ignores it by default?
Sigh!
M hv.c
M hv.h
M hv_vtbl.c
M hv_vtbl.h
M perl.c
commit 4fe95477592d5e5372fc184314c80ff95491992c
Author: Steffen Mueller <[email protected]>
Date: Thu Feb 2 21:19:16 2017 +0100
Hash vtables: More TODO markers
Including describing a potential plan to validate that we've
(eventually) wrapped all hash access operations and nothing in core is
violating any of the encapsulations.
M hv_vtbl.h
commit 83b5d5a3726816d1fb7056480fa9f894d704bf1c
Author: Steffen Mueller <[email protected]>
Date: Thu Feb 2 18:04:39 2017 +0100
Hash vtavbles: hv_store and friends
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 79f3dbeae9286afa614fdfdfaf05e916358f57d8
Author: Steffen Mueller <[email protected]>
Date: Thu Feb 2 18:03:35 2017 +0100
Hash vtables: Expose the damned flag on hv_undef
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 4abb2c6f8407916f33f001dc71c30db168dbdcc2
Author: Steffen Mueller <[email protected]>
Date: Thu Feb 2 09:56:26 2017 +0100
Hash vtables: Add some TODO markers
M hv_vtbl.h
commit 2f7311948f462ba7ad8cce2f9f384d408b3568b6
Author: Steffen Mueller <[email protected]>
Date: Thu Feb 2 09:55:16 2017 +0100
Hash vtables: Expose hv_undef
Sigh. The hash API is way "richer" than I'd like it to be!
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 17bca98cfc91005343439741500d58b27eb54bf4
Author: Steffen Mueller <[email protected]>
Date: Mon Jan 30 09:18:42 2017 +0100
Hash vtables: Only run vtable init if it's not NULL
M hv.c
M hv.h
commit 3e3725c9cbf91d4e350e3bb4c8f541ea14604794
Author: Steffen Mueller <[email protected]>
Date: Sat Jan 28 18:45:46 2017 +0100
Hash vtables: Use macros for access to vtables
M hv.c
commit 253dd5b4986fca397177112634de15503d5a25aa
Author: Steffen Mueller <[email protected]>
Date: Sat Jan 28 17:46:10 2017 +0100
Hash vtables: Add simple accessor macros
M hv_vtbl.h
commit 2eaa95ab81ed8bb4fdb204bcb0d0fc21ffdaba6c
Author: Steffen Mueller <[email protected]>
Date: Fri Jan 27 22:06:05 2017 +0100
Hash vtables: Support mock version of fetch(_ent)
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit dd6cd6251acf257acaf212b073c9094487599bec
Author: Steffen Mueller <[email protected]>
Date: Thu Jan 26 10:10:18 2017 +0100
Hash vtables: make exists and delete use the passthrough trick
Not proud. :(
M hv.c
M hv_vtbl.c
commit 6501e67c317c1bb24988f158e607e3e951989c98
Author: Steffen Mueller <[email protected]>
Date: Thu Jan 26 10:09:46 2017 +0100
Hash vtables: Use correct parameter type
M hv_vtbl.c
M hv_vtbl.h
commit bc1825de57a4b4dcac083f422240b6f33ee21078
Author: Steffen Mueller <[email protected]>
Date: Wed Jan 25 21:27:39 2017 +0100
Hash vtables: hv_clear equivalent
Best I can tell, this leaves the ugly two cases: fetch and store. Kind
of important I suppose...
But really, while I can follow it (generally), I'm not a fan of the
density of hv_common. Very resistant to gentle refactoring. :(
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 1ee8166460f5467f91dcd7fceb0c89c0f87cd2b3
Author: Steffen Mueller <[email protected]>
Date: Wed Jan 25 20:04:44 2017 +0100
Hash vtables: Move vtable testing hook
From newHV() to sv_upgrade() because that should now literally be the
place all hash allocations go through. (Famous last...)
M hv.h
M sv.c
commit 460d35fc0db29552cd56f75504b97055eb446362
Author: Steffen Mueller <[email protected]>
Date: Wed Jan 25 20:04:27 2017 +0100
Hash vtables: exists shim
M hv.c
M hv_vtbl.c
M hv_vtbl.h
commit 2c16c3d45789a496996892c5518efaa60e84a9e6
Author: Steffen Mueller <[email protected]>
Date: Wed Jan 25 16:19:20 2017 +0100
Hash vtables: Add hooks for init/destroy
Also implements empty hooks in the mock example of the standard hash
implementation.
M hv.c
M hv_vtbl.c
M hv_vtbl.h
M sv.c
commit 8459371399552e55c25ce4423ba44563a78cf33f
Author: Steffen Mueller <[email protected]>
Date: Wed Jan 25 16:16:09 2017 +0100
Hash vtables: Regen for previous commit
M embed.h
M proto.h
commit f7a0c061d52bc4d1807145fc5bd79ce5741ceb70
Author: Steffen Mueller <[email protected]>
Date: Wed Jan 25 16:15:50 2017 +0100
Hash vtables: Fix warning: Introduce PERL_IN_HV_VTBL_C
M embed.fnc
M hv_vtbl.c
commit 46f99caecf38e4f181dd81659ea8741e44954419
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.
M MANIFEST
M Makefile.SH
M embed.fnc
M embed.h
M hv.c
M hv.h
A hv_vtbl.c
A hv_vtbl.h
M proto.h
-----------------------------------------------------------------------
--
Perl5 Master Repository
