mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-11-27 15:41:46 +00:00
51944e78bb
We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834 |
||
|---|---|---|
| .. | ||
| API | ||
| Shell | ||
| Unit | ||
| CMakeLists.txt | ||
| lit.cfg.py | ||
| lit.site.cfg.py.in | ||