fix(tracing): reduce stack memory when tracing

[gbrew]

A quick and easy fix for #5522 : Keep the trace stacks as a Vec rather than a Stack struct, as the latter always allocates space for a full 1024 stack items. This can add up to many GB of memory when tracing. The cloned Vec will not be fully allocated.

I believe this should not change tracing behavior. When I was checking the parity vmTraces though, it does look like the current "push" stack element reporting is broken, so that's a separate bug that I'll file.

[mattsse]

how does this fix the referenced issue?

If I'm reading this correctly, then all this does is moving the wrapped Vec out of the Stack, which has no memory benefits

[mattsse]

When I was checking the parity vmTraces though, it does look like the current "push" stack element reporting is broken, so that's a separate bug that I'll file.

please do, that's very likely

[mattsse]

okay, so even if this does not reduce memory, we should still use the underlying vec

ref bluealloy/revm#876

[mattsse]

@gbrew can you please format this?

unable to push because opened from main

[gbrew]

okay, so even if this does not reduce memory, we should still use the underlying vec

ref bluealloy/revm#876

Yeah, I had assumed that Stack::clone() would be fully reserved because it would be memory unsafe if it wasn't.

[gbrew]

@gbrew can you please format this?

unable to push because opened from main

Done, I think? Sorry, I had run the recommended fmt command from Contributing.md ( cargo +nightly fmt -- --check ) before pushing, but it spewed thousands of lines of complaints so I ignored it. I see now that the CI gets it to run clean. Is there some trick to running it?

[mattsse]

looks like latest nightly fmt is still broken...

[gbrew]

looks like latest nightly fmt is still broken...

Good to know! Looks like it actually works fine for me on linux but not on macos.

[mattsse]

right apparently only macos affected