search for: numtombstones

This series of patches address several issues causing memory usage to grow indefinetely on a long lived process. These are not convenional leaks -- memory would have been freed when the LLVM context or/and JIT engine is destroyed -- but for as long as they aren't the memory is usage effectively ubounded. The issues were found using valgrind with '--show-reachable=yes' option: 1.

...of zeroing of all fields of RHS in the body of this constructor if the declaration of the constructor uses move semantics? Here is the consturctor code below: *StringMapImpl(StringMapImpl &&RHS)* * : TheTable(RHS.TheTable), NumBuckets(RHS.NumBuckets),* * NumItems(RHS.NumItems), NumTombstones(RHS.NumTombstones),* * ItemSize(RHS.ItemSize) {* * RHS.TheTable = nullptr;* * RHS.NumBuckets = 0;* * RHS.NumItems = 0;* * RHS.NumTombstones = 0;* * }* Thank you very much! BR, Valeriy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

...Array of NumBuckets pointers to entries, null pointers are holes. // TheTable[NumBuckets] contains a sentinel value for easy iteration. Followed // by an array of the actual hash values as unsigned integers. StringMapEntryBase **TheTable; unsigned NumBuckets; unsigned NumItems; unsigned NumTombstones; unsigned ItemSize; *protected:* explicit StringMapImpl(unsigned itemSize) : TheTable(nullptr), is the second "protected:" a coding style that should be preserved? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piperma...

...lvm/ADT/DenseMap.h +++ b/include/llvm/ADT/DenseMap.h @@ -289,11 +289,14 @@ private: // table completely filled with tombstones, no lookup would ever succeed, // causing infinite loops in lookup. ++NumEntries; - if (NumEntries*4 >= NumBuckets*3 || - NumBuckets-(NumEntries+NumTombstones) < NumBuckets/8) { + if (NumEntries*4 >= NumBuckets*3) { this->grow(NumBuckets * 2); LookupBucketFor(Key, TheBucket); } + if (NumBuckets-(NumEntries+NumTombstones) < NumBuckets/8) { + this->grow(NumBuckets); + LookupBucketFor(Key, TheBucket); + }...

On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: > This series of patches address several issues causing memory usage to grow > indefinetely on a long lived process. Thanks for working on this. Did you measure the performance impact of these changes? /jakob

...// probe almost the entire table until it found the empty bucket. If the // table completely filled with tombstones, no lookup would ever succeed, // causing infinite loops in lookup. + ++NumEntries; if (NumEntries*4 >= NumBuckets*3 || NumBuckets-(NumEntries+NumTombstones) < NumBuckets/8) { this->grow(NumBuckets * 2); LookupBucketFor(Key, TheBucket); } - ++NumEntries; // If we are writing over a tombstone, remember this. if (!KeyInfoT::isEqual(TheBucket->first, getEmptyKey())) ------------------------------------------...

...reduce memory usage; there might be some cases (e.g., frequent updates with a small bounded number of elements) where it may trade off an exponentially growing table size (i.e., memory) for more rehashes (i.e., cpu), but that should be a win on nowadays processors. - patch 4 (Reset StringMap's NumTombstones on clears and rehashes) should improve performance - patch 5 refers to a function that doesn't get called frequently Jose

Thanks, I tried calling ResetAllOptionOccurrences after the run like this… // Compile the module TimeCompilations times to give better compile time // metrics. for (unsigned I = TimeCompilations; I; --I) if (int RetVal = compileModule(argv, Context)) return RetVal; if (YamlFile) YamlFile->keep(); cl::ResetAllOptionOccurrences(); return 0; } Unfortunately