diff options
| author | Snehasish Kumar <snehasishk@google.com> | 2021-10-11 15:03:29 -0700 |
|---|---|---|
| committer | Snehasish Kumar <snehasishk@google.com> | 2021-11-11 11:29:36 -0800 |
| commit | 1243cef245f6131c093d65235e87319e8e124e7f (patch) | |
| tree | d280862960531e49fe1ff03fef125bd3edc0784c /lldb/source/Plugins/ScriptInterpreter/Python/PythonReadline.cpp | |
| parent | fc7162414ede116a453ddb402a55f67d8e50c31b (diff) | |
| download | llvm-1243cef245f6131c093d65235e87319e8e124e7f.zip llvm-1243cef245f6131c093d65235e87319e8e124e7f.tar.gz llvm-1243cef245f6131c093d65235e87319e8e124e7f.tar.bz2 | |
[memprof] Replace the block cache with a hashmap.
The existing implementation uses a cache + eviction based scheme to
record heap profile information. This design was adopted to ensure a
constant memory overhead (due to fixed number of cache entries) along
with incremental write-to-disk for evictions. We find that since the
number to entries to track is O(unique-allocation-contexts) the overhead
of keeping all contexts in memory is not very high. On a clang workload,
the max number of unique allocation contexts was ~35K, median ~11K.
For each context, we (currently) store 64 bytes of data - this amounts
to 5.5MB (max). Given the low overheads for a complex workload, we can
simplify the implementation by using a hashmap without eviction.
Other changes:
* Memory map is dumped at the end rather than startup. The relative
order in the profile dump is unchanged since we no longer have evicted
entries at runtime.
* Added a test to check meminfoblocks are merged.
Differential Revision: https://reviews.llvm.org/D111676
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/PythonReadline.cpp')
0 files changed, 0 insertions, 0 deletions
