[clangd] Introduce memory dumping to FileIndex, FileSymbols and BackgroundIndex

[kadircet]

Summary

File-granular information is considered details.

Depends on D88411

[kadircet]

• Rebase

[sammccall]

clang-tools-extra/clangd/index/Background.cpp

419

Hmm, we should be careful now, estimateMemoryUsage() is "total" while addUsage takes "self".

We're not overriding estimateMemoryUsage here to include IndexedSymbols, but this is probably just an oversight. Consider calling SwapIndex::estimateMemoryUsage() explicitly to guard/communicate against this.

In the long-run, we should put attachMemoryUsage on SymbolIndex and either remove estimateMemoryUsage() or make it non-virtual (MemoryTree R; attachMemoryUsage(R); return R.total())

clang-tools-extra/clangd/index/Background.h

176

As a conventional name for these, profile() or so might be slightly more evocative. And I think we should push this into progressively more places (that currently have ad-hoc "estimate" accessors) so the brevity is reasonable I think.

(If not, I'd even slightly prefer "record"/"measure" over "attach" as emphasizing the high-level operation rather than the data structure used can help readability)

clang-tools-extra/clangd/index/FileIndex.cpp

380

addChild("symbols"/"refs"/"relations")?
This seems like really useful information

459

addChild("preamble").addChild("symbols")?

[kadircet]

• Rename attachMemoryUsage to profile
• Split file symbols into symbols/refs/relations granularity
• Rebase

[sammccall]

Now there's lots of usage (which looks good!) i'm finding it a bit hard to keep track of what the tree will look like overall.

At some point it'd be great to:
a) bind this to an LSP extension so we can see it in editors
b) add a lit test that calls that extension method and includes a dump of the output

[kadircet]

In D88414#2317106, @sammccall wrote:

Now there's lots of usage (which looks good!) i'm finding it a bit hard to keep track of what the tree will look like overall.

At some point it'd be great to:
a) bind this to an LSP extension so we can see it in editors

i was also thinking about it and couldn't decide between a "custom command" vs "code action".

• the former gives a richer interaction, but requires every editor plugin to implement support.
• the latter is a little bit more restrictive but doesn't require a bunch of extra work.

I am happy to go with the "code action" approach initially. WDYT? (not in the scope of this patch)

[kadircet]

• Fix a bug in FileSymbols profiling.
• Add unittests to ensure tree structure is as expected.

[sammccall]

In D88414#2319161, @kadircet wrote:

In D88414#2317106, @sammccall wrote:

Now there's lots of usage (which looks good!) i'm finding it a bit hard to keep track of what the tree will look like overall.

At some point it'd be great to:
a) bind this to an LSP extension so we can see it in editors

i was also thinking about it and couldn't decide between a "custom command" vs "code action".

• the former gives a richer interaction, but requires every editor plugin to implement support.
• the latter is a little bit more restrictive but doesn't require a bunch of extra work.

I am happy to go with the "code action" approach initially. WDYT? (not in the scope of this patch)

I'm pretty leery about code action because it's not at all context-sensitive (not even per-file).
That also doesn't give us any way to specify detail vs summary if we want that.
I'd suggest a custom LSP method (unless there's some reason to prefer executeCommand? Seems like additional indirection for no benefit).

[sammccall]

In D88414#2320859, @sammccall wrote:

In D88414#2319161, @kadircet wrote:

In D88414#2317106, @sammccall wrote:

Now there's lots of usage (which looks good!) i'm finding it a bit hard to keep track of what the tree will look like overall.

At some point it'd be great to:
a) bind this to an LSP extension so we can see it in editors

i was also thinking about it and couldn't decide between a "custom command" vs "code action".

• the former gives a richer interaction, but requires every editor plugin to implement support.
• the latter is a little bit more restrictive but doesn't require a bunch of extra work.

I am happy to go with the "code action" approach initially. WDYT? (not in the scope of this patch)

I'm pretty leery about code action because it's not at all context-sensitive (not even per-file).

Another slighty silly reason: because of layering, a code action is going to have a hard time getting at ClangdLSPServer's profile (or even ClangdServer's).
Whereas a custom method will be implemented at that layer.

(We could work around this in various ways, but I think we'll create a bit of a mess)

clang-tools-extra/clangd/index/Background.h

 #include "index/BackgroundRebuild.h"
 #include "index/FileIndex.h"
 #include "index/Index.h"
 #include "index/Serialization.h"
 #include "support/Context.h"
 #include "support/Path.h"
 #include "support/Threading.h"
 #include "support/ThreadsafeFS.h"
+#include "support/Trace.h"
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/Support/Threading.h"
 #include <atomic>
 #include <condition_variable>
 #include <deque>
 #include <mutex>
 #include <queue>
public:
   }
 
   // Wait until the queue is empty, to allow deterministic testing.
   LLVM_NODISCARD bool
   blockUntilIdleForTest(llvm::Optional<double> TimeoutSeconds = 10) {
     return Queue.blockUntilIdleForTest(TimeoutSeconds);
   }
 
+  MemoryTree getMemoryUsage() const;
+
 private:
   /// Represents the state of a single file when indexing was performed.
   struct ShardVersion {
     FileDigest Digest{{0}};
     bool HadErrors = false;
   };
 
   /// Given index results from a TU, only update symbols coming from files with

clang-tools-extra/clangd/index/Background.cpp

for (auto &LS : Result) {
     // FIXME: Try looking at other TUs if no compile commands are available
     // for this TU, i.e TU was deleted after we performed indexing.
     TUsToIndex.insert(TUForFile);
   }
 
   return {TUsToIndex.begin(), TUsToIndex.end()};
 }
 
+MemoryTree BackgroundIndex::getMemoryUsage() const {
+  MemoryTree MT;
+  MT.addChild("symbols", IndexedSymbols.getMemoryUsage(), true);
+  MT.addChild("index", estimateMemoryUsage());
+  return MT;
+}
 } // namespace clangd
 } // namespace clang

clang-tools-extra/clangd/index/FileIndex.h

 #include "Index.h"
 #include "MemIndex.h"
 #include "Merge.h"
 #include "index/CanonicalIncludes.h"
 #include "index/Ref.h"
 #include "index/Relation.h"
 #include "index/Serialization.h"
 #include "index/Symbol.h"
+#include "support/MemoryTree.h"
 #include "support/Path.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include <memory>
public:
   /// Will count Symbol::References based on number of references in the main
   /// files, while building the index with DuplicateHandling::Merge option.
   /// Version is populated with an increasing sequence counter.
   std::unique_ptr<SymbolIndex>
   buildIndex(IndexType,
              DuplicateHandling DuplicateHandle = DuplicateHandling::PickOne,
              size_t *Version = nullptr);
 
+  MemoryTree getMemoryUsage() const;
+
 private:
   struct RefSlabAndCountReferences {
     std::shared_ptr<RefSlab> Slab;
     bool CountReferences = false;
   };
   mutable std::mutex Mutex;
 
   size_t Version = 0;
public:
   void updatePreamble(PathRef Path, llvm::StringRef Version, ASTContext &AST,
                       std::shared_ptr<Preprocessor> PP,
                       const CanonicalIncludes &Includes);
 
   /// Update symbols and references from main file \p Path with
   /// `indexMainDecls`.
   void updateMain(PathRef Path, ParsedAST &AST);
 
+  MemoryTree getMemoryUsage() const;
+
 private:
   bool UseDex; // FIXME: this should be always on.
   bool CollectMainFileRefs;
 
   // Contains information from each file's preamble only. Symbols and relations
   // are sharded per declaration file to deduplicate multiple symbols and reduce
   // memory usage.
   // Missing information:

clang-tools-extra/clangd/index/FileIndex.cpp

 #include "index/Ref.h"
 #include "index/Relation.h"
 #include "index/Serialization.h"
 #include "index/Symbol.h"
 #include "index/SymbolID.h"
 #include "index/SymbolOrigin.h"
 #include "index/dex/Dex.h"
 #include "support/Logger.h"
+#include "support/MemoryTree.h"
 #include "support/Path.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/Index/IndexingAction.h"
 #include "clang/Index/IndexingOptions.h"
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/Optional.h"
return std::make_unique<dex::Dex>(
         std::move(AllRelations),
         std::make_tuple(std::move(SymbolSlabs), std::move(RefSlabs),
                         std::move(RefsStorage), std::move(SymsStorage)),
         StorageSize);
   }
   llvm_unreachable("Unknown clangd::IndexType");
 }
 
+MemoryTree FileSymbols::getMemoryUsage() const {
+  MemoryTree MT;
+  std::lock_guard<std::mutex> Lock(Mutex);
+  for (const auto &SymSlab : SymbolsSnapshot)
+    MT.addChild(SymSlab.first(), SymSlab.second->bytes());
+  for (const auto &RefSlab : RefsSnapshot)
+    MT.addChild(RefSlab.first(), RefSlab.second.Slab->bytes());
+  for (const auto &RelSlab : SymbolsSnapshot)
+    MT.addChild(RelSlab.first(), RelSlab.second->bytes());
+  return MT;
+}
+
 FileIndex::FileIndex(bool UseDex, bool CollectMainFileRefs)
     : MergedIndex(&MainFileIndex, &PreambleIndex), UseDex(UseDex),
       CollectMainFileRefs(CollectMainFileRefs),
       PreambleIndex(std::make_unique<MemIndex>()),
       MainFileIndex(std::make_unique<MemIndex>()) {}
 
 void FileIndex::updatePreamble(PathRef Path, llvm::StringRef Version,
                                ASTContext &AST,
auto NewIndex = MainFileSymbols.buildIndex(
     MainFileIndex.reset(std::move(NewIndex));
     vlog(
         "Build dynamic index for main-file symbols with estimated memory usage "
         "of {0} bytes",
         MainFileIndex.estimateMemoryUsage());
   }
 }
 
+MemoryTree FileIndex::getMemoryUsage() const {
+  MemoryTree MT;
+  MT.addChild("preamble_symbols", PreambleSymbols.getMemoryUsage(), true);
+  MT.addChild("preamble_index", PreambleIndex.estimateMemoryUsage());
+  MT.addChild("main_file_symbols", MainFileIndex.estimateMemoryUsage());
+  MT.addChild("main_file_index", MainFileSymbols.getMemoryUsage(), true);
+  return MT;
+}
 } // namespace clangd
 } // namespace clang