[cDAC] Hashtable contracts simplification

[jkotas]

The runtime has a number of different implementations of hashtables for historic reasons. It is not desirable to create cDac contracts for all of them.

• Review hashtable usages that need to part of cDac contract
• Unify on one good hashtable implementation that we like

[max-charlamb]

These are the runtime hashtable implementations I've come across, are there others I am missing?

• DacEnumerableHashTable
• HashMap
• SHash

[jkotas]

Here are a few more:

• CHashtable
• EEHash
• dn-simdhash - not DACzied currently, has interesting ideas
• Native AOT fork of SHash

Outside the scope of this issue:

• JitHashTable - not DACize
• SimplerHash - not DACized, only used in one place, can be unified with JitHashTable
• dn-umap - only used by Mono

[lateralusX]

• dn-umap - only used by Mono

It is used by EventPipe so used by all runtimes.

[lateralusX]

Maybe it's time to standardize on some version of what's implemented in native/containers or adjust/complement existing implementation of hashtables in the container library, dn-umap/dn-simdhash?

[jkotas]

HashMap, EEHash and DacEnumerableHashTable are lock-free for reading. It is important for scalability.

Meta point is that performance (time, memory, scalability, code size) is important factor to consider with any unifications.

[am11]

HashMap, EEHash and DacEnumerableHashTable are lock-free for reading. It is important for scalability.

It sounds like the unified API (e.g. minipal_hashmap_init) might eventually take a MINIPAL_HASHMAP_OPTIMIZED_FOR_READING flag, defaulting to a balanced algorithm when not specified.