This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Use atomics instead of locks to track periodic memory trimming
ClosedPublic

Authored by sammccall on Dec 22 2020, 12:36 PM.

Details

Summary

Instead of always locking/unlocking a contended mutex, we now do one atomic read
in the common case, and one read + one exchange if the timer has expried.

Also use this for memory profiling which has similar/compatible requirements.

Diff Detail

Event Timeline

sammccall created this revision.Dec 22 2020, 12:36 PM
sammccall requested review of this revision.Dec 22 2020, 12:36 PM
qchateau accepted this revision.Dec 22 2020, 1:12 PM

LGTM

Small nits:

  • operator() is not const but Next is mutable, seems to me you intended to have operator() as const
  • memory orders for the atomic operations can probably be downgraded to std::memory_order_acquire/std::memory_order_acq_rel. I think the first load can even be relaxed but that I'm always careful with these
This revision is now accepted and ready to land.Dec 22 2020, 1:12 PM

LGTM

Small nits:

  • operator() is not const but Next is mutable, seems to me you intended to have operator() as const

Oops, I originally did plan to make operator() const, but then decided it'd be clearer for the caller to make PeriodicThrottler mutable instead. (Because pretending it doesn't have state is confusing).
Removed mutable from Next.

  • memory orders for the atomic operations can probably be downgraded to std::memory_order_acquire/std::memory_order_acq_rel. I think the first load can even be relaxed but that I'm always careful with these

Done. I have to confess I often pretend memory orders other than seq_cst don't exist just to keep the cognitive load down, but this case seems clear/isolated enough.

This revision was landed with ongoing or failed builds.Dec 22 2020, 1:32 PM
This revision was automatically updated to reflect the committed changes.