[PATCH] D125979: [ADT] add ConcurrentHashTable class.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added inline comments.


================
Comment at: llvm/include/llvm/ADT/ConcurrentHashTable.h:117-118
+    else if (CurSlabNum > MaxNumberOfSlabs)
+      reportWarning("Too many slabs. Consider increasing initial size or "
+                    "changing hash function.");
+
----------------
avl wrote:
> dblaikie wrote:
> > It's pretty weird to have warnings coming out of data structures. @MaskRay would it be reasonable to remove these/replace them with some other tool if we're promoting this to a more general purpose data structure rather than something more special-case in lld?
> Probably, instead of warning we can introduce method:
> 
> ```
> bool IsInGoodState () const {
>   return CurSlabNum <= MaxNumberOfSlabs && !hasFullSlab;
> }
> 
> 
> ```
> 
> the consumer could call this method somewhere and inform the user:
> 
> ```
> if (!HashTable.IsInGoodState()) {
>     outs() << "Hash table is in suboptimal state";
> }
> ```
> 
> ?
Maybe? I'd be curious to hear from @MaskRay here, since I guess he wrote the original/had the original motivation for the warning.


================
Comment at: llvm/include/llvm/ADT/ConcurrentHashTable.h:315-316
+///
+/// It is recommended to use ConcurrentHashTableExtAlloc if sizeof(KeyDataTy) >
+/// sizeof(pointer).
+///
----------------
avl wrote:
> dblaikie wrote:
> > This should probably be provided via specialization, rather than as a separately named type?
> > 
> > I guess it has different requirements for the type, by the looks of it? That's curious/maybe enough to warrant a separate name, I guess, though I'm not 100% sure.
> They have different interface:
> 
> 
> ```
> std::pair<KeyDataTy, bool> insert(KeyDataTy NewData)
> ```
> and
> ```
> std::pair<KeyDataTy *, bool> insert(AllocatorTy &Allocator, KeyTy Key)
> ```
> 
> Implementing this through the specialization looks to be more complex and it seems does not have benefits comparing to the variant with separately named types?
Fair enough. I wonder if it'd be acceptable to have the hash table take the allocator as a ctor parameter (& then keep the same API otherwise) and store it, or if there are too many of these that the extra pointer member would be too costly.

Though coming back to the original comment - why is external allocation usage/recommendation related to the size of the keys/size of a pointer?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125979/new/

https://reviews.llvm.org/D125979