Ben Kimock

The relevant code is here: https://github.com/rust-fuzz/cargo-fuzz/blob/95f7737d511059b72eb0be53d3e3c6e8959127bf/src/utils.rs#L1-L4 `current_platform` documents that > Platform information is resolved at compile time, based on the platform for which your code is compiled. It incurs zero...

Oh jeez I didn't realize this project was uploading musl releases 🤦 That's just an oversight, nobody realized what that does. I'm a bit surprised nobody has reported this problem...

Ah! Yes. The library simply does not have such a mapping at all, which means that our shim doesn't know how to construct strings for errors not exposed by the...

I think at one point I started working on all of these then backed out. So here are some notes. > * Mappings populated with `MAP_POPULATE`, Is this useful without...

> and we map it gradually page-by-page using `mremap` Do you rely on multiple `mremap` calls extending a single allocation? Or is the address range made available by each `mremap`...

It looks like the behavior of rustdoc that cargo-miri was relying on changed in the 2024 edition. I'm sure it changed for the better, we just need equivalent tweaks to...

> Replacing `[*mut AtomicPage; PAGES]` with `[Box; PAGES]` reduces slowdown to less than 2x. I cannot reproduce this result. Can you post the version that uses `Box`?

> Interestingly, keeping the `page` variable results in a ~30x slowdown: There is an extremely subtle difference between those two programs. You're specifying the type to be `&AtomicPage`, but without...

Hunh. In fact adding the type annotation _at all_, even if it's fully redundant, still produces an extra reborrow. That is new to me.

Ah of course, the primary issue with debugging this performance issue is that the GC is doing its absolute best to cover up the problem. Perhaps a better minimization is...