Re: [PATCH 00/19] Add hash table to gdbsupport

[Tom Tromey <tom@tromey.com>]

>>>>> "John" == John Baldwin <jhb@FreeBSD.org> writes:

John> On 4/7/23 8:25 AM, Tom Tromey wrote:
>> I recently read an article about hash tables and was inspired to write
>> a new one for gdb.  I haven't converted all the libiberty htab uses in
>> gdb, but this series does change enough of them to, I think, show that
>> the new implementation is workable.
>> The benefits of this approach are explained in the first patch.
>> Regression tested on x86-64 Fedora 36.  This found a latent bug in
>> one
>> use of htab_t, see the typedefs patch.
>> Let me know what you think.

John> I just have one possibly naive question which is why not use
John> std::unordered_map<> directly in the various callers?  At least, I think
John> it might be useful to explain why GDB includes a bespoke hash table now
John> that we require C++11, it was more obvious I think when GDB was still
John> written in C.

std::unordered_map has some issues.  They may not affect every spot
using hash tables in gdb, but they probably affect some of them.

unordered_map is necessarily a chained hash table, not an open addressed
hash table.  And, it has to allocate nodes for entries, because it
promises pointer stability.  So, it has higher overhead than the hash
table in this series.

Also, I don't think there's a way to use one type as the key in
unordered_map but do lookups using a different type.  gdb uses this in
some places.

I'll add some text to this effect to patch #1.

Tom