Isolate MiriMachine memory from Miri's #4343

nia-e · 2025-05-22T12:05:04Z

Based on discussion surrounding #4326, this merges in the (very simple) discrete allocator that the MiriMachine will have. See the design document linked there there for considerations, but in brief: we could pull in an off the shelf allocator for this, but performance isn't a massive worry and doing it this way might make it easier to enable support for doing multi-seeded runs in the future (without a lot more extraneous plumbing, at least)

nia-e · 2025-05-22T12:41:08Z

@rustbot ready

RalfJung

Thanks for the PR! I left some first comments, but this is not a full review. I'd rather not reverse-engineer the invariants of MachineAlloc myself, so I'll wait for you to document them, which will make review a lot easier.

Furthermore, all pub fn in discrete_alloc should have proper doc comments, not just a safety comment. Please also add some basic unit tests -- we don't use them much in Miri, but this is one of the cases where they would make sense.

On Zulip you mentioned some benchmarks. Can you put benchmark results for the variant that you ended up going for here into the PR?

Cargo.toml

src/discrete_alloc.rs

src/machine.rs

RalfJung · 2025-05-24T12:49:16Z

@rustbot author

rustbot · 2025-05-24T12:49:19Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

nia-e · 2025-05-24T15:05:31Z

I'll post benchmarks in a bit! I realised there might be some speed gains to be made with very simple changes, so I'll just experiment a little first. Thanks for the comments ^^

nia-e · 2025-05-24T15:50:15Z

Baseline is set to having the allocator fully disabled. It's only marginally slower in most cases, though it struggles with large allocations it seems. I wonder how much work it would be to improve that, but if we go down the "only machines using this will touch it" path I hope it's not too bad? I got a slight (~4%) improvement from calling mmap directly instead of calling alloc::alloc() but I doubt that's worth it. Is Miri built with optimisations on by default when invoking ./miri bench?

Comparison with baseline (relative speed, lower is better for the new results):
  backtraces: 1.36 ± 0.08
  big-allocs: 32.71 ± 1.60
  mse: 1.05 ± 0.10
  range-iteration: 1.06 ± 0.03
  serde1: 1.00 ± 0.03
  serde2: 1.06 ± 0.03
  slice-chunked: 1.03 ± 0.04
  slice-get-unchecked: 0.93 ± 0.08
  string-replace: 1.06 ± 0.04
  unicode: 1.06 ± 0.05
  zip-equal: 1.08 ± 0.02

RalfJung · 2025-05-24T15:54:19Z

Is Miri built with optimisations on by default when invoking ./miri bench?

Yes.

A 32x slowdown with big allocations is hefty.^^ Shouldn't those just forward to alloc::alloc anyway as part of the huge allocs treatment? Without looking at the code, what I'd assume happens when the allocation request is close to the page size is: round up to multiple of page size, and then just allocate that and use it directly without any kind of tracking of "which parts of this page are used" or so. That should have basically no overhead.

nia-e · 2025-05-24T15:55:31Z

It does mostly do that, which is what's confusing me... I'll try to fix it, I assume I just missed something really obvious.

nia-e · 2025-05-24T16:38:01Z

I checked; seems like the big-allocs test specifically calls alloc_zeroed which was the reason for the slowdown (apparently ptr.write_bytes() is a really slow way to zero out bytes). I changed up the logic a bit to make the logic generic over calling alloc::alloc() vs alloc::alloc_zeroed() and these are the (much better!) results:

Comparison with baseline (relative speed, lower is better for the new results):
  backtraces: 1.23 ± 0.06
  big-allocs: 1.03 ± 0.05
  mse: 0.99 ± 0.09
  range-iteration: 1.01 ± 0.03
  serde1: 0.99 ± 0.02
  serde2: 1.03 ± 0.02
  slice-chunked: 0.97 ± 0.04
  slice-get-unchecked: 0.89 ± 0.08
  string-replace: 1.00 ± 0.03
  unicode: 1.01 ± 0.04
  zip-equal: 1.05 ± 0.04

I might be able to squeeze a bit more perf out by actually making the functions generic instead of just passing in a function pointer but shrug, unsure if it's necessary

RalfJung · 2025-05-24T16:45:11Z

Ah yes, that is exactly why we added that particular benchmark. :)

nia-e · 2025-05-24T16:46:34Z

What kind of unit tests do you think belong here? I assumed functionality is covered by the usual tests, but I'll happily add in some stuff if you think it's relevant

RalfJung · 2025-05-24T16:50:10Z

What kind of unit tests do you think belong here? I assumed functionality is covered by the usual tests, but I'll happily add in some stuff if you think it's relevant

Similar to range_map: just add some functions with #[test] in the file with the allocator implementation to test some particular corner cases -- or at least a basic smoke test if there are no corner cases.

nia-e · 2025-05-24T18:40:02Z

Openen the PR on the main repo, ~~I'll get to adding tests if everything there is okay~~ it is not okay I need to do more things oops

nia-e · 2025-05-24T21:34:23Z

Expecting the build to fail for now since it's adapted to the changes from the PR (but also Miri seems to be having trouble on the current upstream master commit, so I guess it's pending that being fixed too)

nia-e · 2025-05-24T22:45:24Z

Tests added :D let me know if there's anything more to do

Rollup merge of #141513 - nia-e:allocbytes-extend, r=RalfJung interpret: add allocation parameters to `AllocBytes` Necessary for a better implementation of [rust-lang/miri#4343](rust-lang/miri#4343). Also included here is the code from that PR, adapted to this new interface for the sake of example and so that CI can run on them; the Miri changes can be reverted and merged separately, though. r? `@RalfJung`

interpret: add allocation parameters to `AllocBytes` Necessary for a better implementation of [#4343](#4343). Also included here is the code from that PR, adapted to this new interface for the sake of example and so that CI can run on them; the Miri changes can be reverted and merged separately, though. r? `@RalfJung`

nia-e · 2025-05-27T14:17:06Z

@rustbot ready

src/alloc/isolated_alloc.rs

RalfJung · 2025-05-27T14:56:51Z

src/alloc/isolated_alloc.rs

+use std::alloc::{self, Layout};
+use std::sync;
+
+static ALLOCATOR: sync::Mutex<IsolatedAlloc> = sync::Mutex::new(IsolatedAlloc::empty());


I was hoping we wouldn't need this any more and could instead store this in the Machine and pass it to the allocation via the params... otherwise, the allocations of multiple native-libs machines could still get mixed here.

But that's harder now that parameters are their own associated type. It should still be possible though, AFAIK lifetime generic associated types are stable?

Sure, I think we can do that; I'll get on it

I'm probably missing something here but simply changing the associated type to something like an Option<&'p std::cell::RefCell<IsolatedAlloc>> means we have to make the MiriMachine a self-referential struct, no? Since GlobalStateInner holds an FxHashMap<AllocId, MiriAllocBytes<'p>> it needs a lifetime, and therefore also GlobalState needs a lifetime...

Maybe instead we can just pass in something like a MachineId in the params and have the allocator keep track of that? That would be quite easy to do, simply have each page store the corresponding MachineId (or equivalently, store a Vec<(Vec<*mut u8>, MachineId)>). That feels like less of a headahce?

Ended up going with a hashmap, but I can change that if you think it's not the right call. I just couldn't see a non-intrusive way to do it outside of either (a) passing a raw pointer instead of a reference (yikes) or (b) using something like Arc<RefCell<IsolatedAllocator>> which I'm not sure is worth the overhead and runtime panic risk

Ok, I've looked into making the ptrace bits compatible with multi-seeded Miri and I'm pretty strongly in favour of this approach because it will also enable us to share one single supervisor process for all of the machines (telling them apart by the seed and propagating that). Though if the C library has shared state across all seeds that will be problematic

Ah I guess now I nerd-sniped you into making the many-seeds thing works for native-libs mode... sorry for that.^^

Just for the allocator, you don't need an ID -- you can entirely avoid even having a global variable here and just store another Rc<...> pointing to the allocator in the machine itself. That would only hold the allocations for that one machine so it can easily list "its" pages (and it also neatly involves having concurrent machines content on the same lock). But I don't know which further constraints are imposed by the ptrace thing.

Yep, what you described is basically what I am doing. And I am now deadset on doing the many-seeds :D I am insisting that there will be Only One Ffi At A Time because otherwise I cannot begin to imagine how to tell e.g. which ffi call is responsible for a particular syscall, but it at least means I only need to deal with one lock on the main supervisor. Also I think fixing the many-seeds thing will make it so it stops having a chance to randomly hang in CI if the native-lib tests run in parallel, which is... undesirable

Would you look at that this fixes everything and multi-seeded mode works perfectly.

I'll wait to double-check with the github CI on the ptrace branch but if it's all good (should be) I'll push here

I am insisting that there will be Only One Ffi At A Time

That sounds like not supporting many-seeds + native-libs? I am confused now.^^

Sorry, I mean many-seeds can coexist but only one can be in "ffi mode" at a time, with the others blocking until that one finishes. Otherwise it becomes borderline impossible to trace properly, and perhaps actually impossible when it comes to e.g. intercepting syscalls

src/alloc/isolated_alloc.rs

Co-authored-by: Ralf Jung <post@ralfj.de>

nia-e · 2025-05-27T20:00:55Z

@rustbot ready

nia-e · 2025-05-27T20:07:54Z

Ah seems like it never got passed back to waiting on author so in case it didn't ping you, cc @RalfJung

RalfJung · 2025-05-28T08:40:34Z

Based on #4343 (comment) I assume this is @rustbot author again.

nia-e · 2025-05-28T09:25:19Z

Did it all via Rc<RefCell<IsolatedAllocator>>s, and it is indeed so much cleaner...

@rustbot ready

RalfJung

I didn't look into the actual allocator yet, just the glue code around it.

RalfJung · 2025-05-28T10:21:04Z

src/alloc/alloc_bytes.rs

        let slice = slice.into();
        let size = slice.len();
        let align = align.bytes();
+        let p_clone = params.clone();


Why is this getting cloned here? That should not be needed.

Not entirely sure why but trying to match on params.clone() complained, but this didn't. I'll look into it, I left that as mostly a placeholder to check what's happening but ty for reminding me

Seems like it's because it needs to get captured in the closure below, so it needs its own copy. Maybe it can also be fnonce, I'll see

RalfJung · 2025-05-28T10:21:12Z

src/alloc/alloc_bytes.rs

        let size = size.bytes();
        let align = align.bytes();
+        let p_clone = params.clone();


Same here regarding cloning.

RalfJung · 2025-05-28T10:22:02Z

src/concurrency/thread.rs

@@ -905,7 +906,7 @@ pub trait EvalContextExt<'tcx>: crate::MiriInterpCxExt<'tcx> {
                    interp_ok(MiriAllocBytes::from_bytes(
                        std::borrow::Cow::Borrowed(bytes),
                        align,
-                        (),
+                        params.clone(),


Ah damn, this closure should be a FnOnce and not FnMut and then we can avoid a clone here...
Could you make a rustc PR for that?

RalfJung · 2025-05-28T10:22:24Z

src/machine.rs

+        let seed = config.seed.unwrap_or(0);
+        let rng = StdRng::seed_from_u64(seed);


Why did you change this?

This was for when I was using the seeds as machine ids, oops! Will revert

src/machine.rs

RalfJung · 2025-05-28T10:23:04Z

src/machine.rs

@@ -532,6 +532,10 @@ pub struct MiriMachine<'tcx> {
    /// Needs to be queried by ptr_to_int, hence needs interior mutability.
    pub(crate) rng: RefCell<StdRng>,

+    /// The allocator used for the machine's `AllocBytes`.
+    #[cfg(target_os = "linux")]
+    pub(crate) allocator: Rc<RefCell<crate::alloc::isolated_alloc::IsolatedAlloc>>,


This should be Option<Rc<...>> since it should only exist in native-libs mode.

Co-authored-by: Ralf Jung <post@ralfj.de>

rustbot added the S-waiting-on-review Status: Waiting for a review to complete label May 22, 2025

nia-e force-pushed the discrete-allocator branch 4 times, most recently from 6cbc283 to b53ed38 Compare May 23, 2025 10:39

RalfJung reviewed May 24, 2025

View reviewed changes

rustbot removed the S-waiting-on-review Status: Waiting for a review to complete label May 24, 2025

rustbot added the S-waiting-on-author Status: Waiting for the PR author to address review comments label May 24, 2025

nia-e force-pushed the discrete-allocator branch from 4b1f50f to 9f1047e Compare May 24, 2025 15:13

nia-e mentioned this pull request May 24, 2025

interpret: add allocation parameters to AllocBytes rust-lang/rust#141513

Merged

nia-e force-pushed the discrete-allocator branch from 87f2b3f to f7fe286 Compare May 24, 2025 22:52

This comment has been minimized.

Sign in to view

nia-e force-pushed the discrete-allocator branch 4 times, most recently from c4ad33f to b832def Compare May 25, 2025 16:20

This comment has been minimized.

Sign in to view

nia-e force-pushed the discrete-allocator branch from 1c9e998 to a75234c Compare May 27, 2025 14:16

rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels May 27, 2025

nia-e force-pushed the discrete-allocator branch 4 times, most recently from 3e177a7 to 3f500d4 Compare May 27, 2025 14:34

add separate allocator for MiriMachine

6794b61

nia-e force-pushed the discrete-allocator branch from 3f500d4 to 6794b61 Compare May 27, 2025 14:37

RalfJung reviewed May 27, 2025

View reviewed changes

nia-e and others added 3 commits May 27, 2025 17:07

Update src/alloc/isolated_alloc.rs

5fcabd9

Co-authored-by: Ralf Jung <post@ralfj.de>

allow multiple seeds

c0fbaea

use bitsets

36b58ce

fix xcompile

ccb844e

rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels May 28, 2025

listened to reason and made my life so much easier

eac36ab

rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels May 28, 2025

fmt

c7aeb25

RalfJung reviewed May 28, 2025

View reviewed changes

Update src/machine.rs

e1f652d

Co-authored-by: Ralf Jung <post@ralfj.de>

		let seed = config.seed.unwrap_or(0);
		let rng = StdRng::seed_from_u64(seed);

Isolate MiriMachine memory from Miri's #4343

Are you sure you want to change the base?

Isolate MiriMachine memory from Miri's #4343

Conversation

nia-e commented May 22, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nia-e commented May 22, 2025

Uh oh!

RalfJung left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RalfJung commented May 24, 2025

Uh oh!

rustbot commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025

Uh oh!

RalfJung commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025

Uh oh!

RalfJung commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nia-e commented May 24, 2025

Uh oh!

nia-e commented May 24, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

nia-e commented May 27, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RalfJung May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nia-e May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

nia-e commented May 22, 2025 •

edited by rustbot

Loading

nia-e commented May 24, 2025 •

edited

Loading

nia-e commented May 24, 2025 •

edited

Loading

RalfJung May 27, 2025 •

edited

Loading

nia-e May 27, 2025 •

edited

Loading

RalfJung left a comment •

edited

Loading