This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Mechanism to make update debounce responsive to rebuild speed.
ClosedPublic

Authored by sammccall on Feb 3 2020, 4:07 AM.

Details

Summary

Currently we delay AST rebuilds by 500ms after each edit, to wait for
further edits. This is a win if a rebuild takes 5s, and a loss if it
takes 50ms.

This patch sets debouncepolicy = clamp(min, ratio * rebuild_time, max).
However it sets min = max = 500ms so there's no policy change or actual
customizability - will do that in a separate patch.

See https://github.com/clangd/clangd/issues/275

Diff Detail

Event Timeline

sammccall created this revision.Feb 3 2020, 4:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2020, 4:07 AM

Unit tests: pass. 62406 tests passed, 0 failed and 839 were skipped.

clang-tidy: fail. clang-tidy found 0 errors and 1 warnings. 1 of them are added as review comments below (why?).

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

hokein accepted this revision.Feb 3 2020, 5:45 AM

looks good, a few nits.

clang-tools-extra/clangd/TUScheduler.cpp
249

nit: maybe move it after the Mutex declaration.

771

nit: update the stale comment.

clang-tools-extra/clangd/TUScheduler.h
66

nit: should be sounds like this is something we haven't done yet? maybe add FIXME?

72

nit: this comment in () seems to be more related to the DebouncePolicy, maybe move it around the class.

This revision is now accepted and ready to land.Feb 3 2020, 5:45 AM
This revision was automatically updated to reflect the committed changes.
sammccall marked 4 inline comments as done.

This seems to break tests: http://45.33.8.238/linux/9296/step_9.txt

Thanks, I've reverted to take a look. It's weird though:

  • don't see this on any lab buildbots or locally
  • the lit test stack traces are all in one specific codepath (in selectiontree) that's totally unrelated
  • the unit test traces aren't symbolized, but if it's the same stack then they never even use TUScheduler

So possible i'm tickling something latent.

thakis added a comment.Feb 4 2020, 7:24 AM

I agree it's a bit strange. The linux bot didn't recover after the revert either, so something's amiss.

My Win bot has been hanging since this landed and I just CRD'd in and it's hanging in check-clangd and there are tens of ClangdTests processes hanging around and doing nothing.

On the more official win bot, instead the link of ClangdTests has been failing since this landed, which on Windows is likely caused by the processes still hanging around (http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/14120/steps/stage%201%20check/logs/stdio). This is the first bad build: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/14113/

sammccall marked an inline comment as done.Feb 4 2020, 8:10 AM

I agree it's a bit strange. The linux bot didn't recover after the revert either, so something's amiss.

My Win bot has been hanging since this landed and I just CRD'd in and it's hanging in check-clangd and there are tens of ClangdTests processes hanging around and doing nothing.

On the more official win bot, instead the link of ClangdTests has been failing since this landed, which on Windows is likely caused by the processes still hanging around (http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/14120/steps/stage%201%20check/logs/stdio). This is the first bad build: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/14113/

Windows: the stacktrace in the first bad build is almost certainly the bug above.
The processes hanging around after a crash (on the main thread) is surprising. The crash is on the main thread, though there are others. Something I should look into.

Linux: (some of) the stacktraces seem very unrelated to this code, and a revert didn't fix them, but a clean rebuild did (thanks @thakis!).

Next step: wait for the gn linux bot to be back in a good state, reland with the double-unlock fixed.

clang-tools-extra/clangd/TUScheduler.cpp
528

Here's a double-unlock (thanks @kadircet)