Memory use grows over time #3080

saethlin · 2023-09-24T05:50:59Z

There are a few places in both the interpreter and the additional Miri runtime where we accumulate state and never release it.

For example, this program uses more memory over time:

fn main() {
    for _ in 0..1_000_000 {}
}

(I like this program because it seems comically simple but of course ranges are quite complicated without any optimization)

There are a few sources of this memory growth. I'm going to try to fix or reduce as many as possible. In most cases the growth is manageable but I have a real world case someone showed me where we hit ~10 GB in just a few minutes due to these issues.

Stacked Borrows Allocation history and in particular the invalidations is the biggest offender. I think we can fix this with the tag GC. I'll send a PR tomorrow.
The spans we save for all allocations/locals are probably next. Not really sure what to do here, maybe also use the tag GC + the set of exposed allocs.
Intptrcast state cannot just be cleaned up on deallocation. I tried doing that and I didn't get the test failures I was hoping to see. Perhaps the tag GC can help us again here, or maybe we can only clean up one side of the mapping.
The dead allocs map in the interpreter. Based on the comments, I don't think we need this in Miri?
Return a finite number of AllocIds per ConstAllocation in Miri rust#118336

The trickiest thing about these is that so far it looks like fixing these problems does not make Miri any faster or slower, and we don't have peak memory benchmarks. And hyperfine doesn't support them.

RalfJung · 2023-09-24T07:04:25Z

Intptrcast state cannot just be cleaned up on deallocation. I tried doing that and I didn't get the test failures I was hoping to see. Perhaps the tag GC can help us again here, or maybe we can only clean up one side of the mapping.

This would need an AllocId GC instead of tag GC, and even then I am not sure whether it is sufficient. We'd have to be very sure that future int2ptr calls behave the same before after after cleanup.

The dead allocs map in the interpreter. Based on the comments, I don't think we need this in Miri?

It will be used at least with -Zmiri-symbolic-alignment.

GC the Stacked Borrows allocation history This handles the biggest contributor to #3080 The benchmark that this adds demonstrates the memory improvement here, but our benchmark setup doesn't record memory usage, and `hyperfine` doesn't support emitting memory usage stats. I ran this benchmark manually with `/usr/bin/time -v cargo +miri miri run` 🤷

GC the Stacked Borrows allocation history This handles the biggest contributor to rust-lang/miri#3080 The benchmark that this adds demonstrates the memory improvement here, but our benchmark setup doesn't record memory usage, and `hyperfine` doesn't support emitting memory usage stats. I ran this benchmark manually with `/usr/bin/time -v cargo +miri miri run` 🤷

saethlin · 2023-10-03T21:44:47Z

We'd have to be very sure that future int2ptr calls behave the same before after after cleanup.

This is what I was getting at with the "+ the set of exposed allocs". I think expose_addr is simply asking for a leak, and so it shall be in the interpreter.

Expand Miri's BorTag GC to a Provenance GC As suggested in rust-lang/miri#3080 (comment) We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those. To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require. r? `@RalfJung`

Expand Miri's BorTag GC to a Provenance GC As suggested in rust-lang/miri#3080 (comment) We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those. To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require. r? ``@RalfJung``

Rollup merge of rust-lang#118029 - saethlin:allocid-gc, r=RalfJung Expand Miri's BorTag GC to a Provenance GC As suggested in rust-lang/miri#3080 (comment) We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those. To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require. r? ``@RalfJung``

Expand Miri's BorTag GC to a Provenance GC As suggested in #3080 (comment) We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those. To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require. r? ``@RalfJung``

saethlin · 2024-02-01T16:08:57Z

Since rust-lang/rust#118336 landed, I think this is done. I don't observe memory growth anymore.

saethlin self-assigned this Sep 24, 2023

saethlin mentioned this issue Sep 25, 2023

GC the Stacked Borrows allocation history #3083

Merged

saethlin mentioned this issue Oct 4, 2023

Extend the BorTag GC to AllocIds #3103

Closed

saethlin mentioned this issue Nov 18, 2023

Expand Miri's BorTag GC to a Provenance GC rust-lang/rust#118029

Merged

saethlin closed this as completed Feb 1, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Memory use grows over time #3080

Memory use grows over time #3080

saethlin commented Sep 24, 2023 •

edited

Loading

RalfJung commented Sep 24, 2023

saethlin commented Oct 3, 2023

saethlin commented Feb 1, 2024

Memory use grows over time #3080

Memory use grows over time #3080

Comments

saethlin commented Sep 24, 2023 • edited Loading

RalfJung commented Sep 24, 2023

saethlin commented Oct 3, 2023

saethlin commented Feb 1, 2024

saethlin commented Sep 24, 2023 •

edited

Loading