diff options
| author | bors <bors@rust-lang.org> | 2023-11-23 08:20:21 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-11-23 08:20:21 +0000 |
| commit | 38eecca62c73401043eb5ff01557bb58792631f7 (patch) | |
| tree | a6d870e8e0347f9e61710f21066c83c6be5f245a /tests/rustdoc-ui/lints/feature-gate-rustdoc_missing_doc_code_examples.stderr | |
| parent | fc13ca6d70f7381513c22443fc5aaee1d151ea45 (diff) | |
| parent | f5dae8e73c3449d76311781ba86aa82034fb5296 (diff) | |
| download | rust-38eecca62c73401043eb5ff01557bb58792631f7.tar.gz rust-38eecca62c73401043eb5ff01557bb58792631f7.zip | |
Auto merge of #118073 - saethlin:gc-dead-allocs, r=RalfJung
Miri: GC the dead_alloc_map too
dead_alloc_map is the last piece of state in the interpreter I can find that leaks. With this PR, all of the long-term memory growth I can find in Miri with programs that do things like run a big `loop {` or run property tests is attributable to some data structure properties in borrow tracking, and is _extremely_ slow.
My only gripe with the commit in this PR is that I don't have a new test for it. I'd like to have a regression test for this, but it would have to be statistical I think because the peak memory of a process that Linux reports is not exactly the same run-to-run. Which means it would have to not be very sensitive to slow leaks (some guesswork suggests for acceptable CI time we would be checking for like 10% memory growth over a minute or two, which is still pretty fast IMO).
Unless someone has a better idea for how to detect a regression, I think on balance I'm fine with manually keeping an eye on the memory use situation.
r? RalfJung
Diffstat (limited to 'tests/rustdoc-ui/lints/feature-gate-rustdoc_missing_doc_code_examples.stderr')
0 files changed, 0 insertions, 0 deletions