Re: Comment simplehash/dynahash trade-offs

On Mon, 3 Aug 2020 at 11:10, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I think you can probably go further, though, and make it require no
> storage at all by making it optionally "intrusive", by using a special
> value in an existing member, and supplying an expression to set and
> test for that value. For example, maybe some users have a pointer but
> never want to use NULL, and maybe some users already have a field
> holding various flags that are one bit wide and can spare a bit.

I agree that it would be good to allow users of simplehash.h that
additional flexibility. It may allow additional memory savings.
However, it would mean we'd need to do some additional work when we
create and grow the hash table to ensure that we mark new buckets as
empty. For now, we get that for free with the zeroing of the newly
allocated memory, but we couldn't rely on that if we allowed users to
define their own macro.

It looks like none of the current callers could gain from this

1. TupleHashEntryData does not have any reusable fields. The status
should fit in the padding on a 64-bit machine anyway.
2. PagetableEntry already has a status that fits into the padding.
3. manifest_file could have its status moved to the end of the struct
and made into a char and the struct would be the same size as if the
field did not exist.

So, with the current users, we'd stand to lose more than we'd gain
from doing it that way.

David