-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EVM: Small patch that reduces EVM stack usage to almost nothing #586
Conversation
# updated and cleared so as to avoid circular and dangling refs. | ||
if c.beforeExec(): | ||
return | ||
c.executeOpcodes() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some exception handling will have to be added here to ensure that each call to snapshot
has a corresponding dispose
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exception is already handled, and in fact if you add more exception handling here you will break it.
See howexecCallOrCreate
is responsible for calling dispose
on the chain of computations linked by parent
, and execCallOrCreateAux
updates the head of the chain. The outer function sees those updates, becausec
is a var
parameter. If this didn't happen, there would be no reason for the loop in the defer
block, in fact no reason for two functions.
That's subtle but it's essential to how the defer
(exception handling) logic is kept in a different stack frame, which allows the inner function to have a smaller stack frame than it would otherwise. Adding a contour of exception handling at the inner function changes stack needed from 80 kB to 300-750 kB for no gain.
I used to have this as two patches, first where there was just execCallOrCreate
, then a second that splits them into these two functions to reduce stack usage more. Perhaps they should have stayed as two patches for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a section to the commit message that explains the exception handling (also edited in the PR message), and clarified it in the code comment.
There's been a lot of talk about the Nimbus EVM "stack problem". I think we assumed changing it would require big changes to the interpreter code, touching a lot of functions. It turned out to be a low hanging fruit. This patch solves the stack problem, but hardly touches anything. The change in EVM stack memory is from 13 MB worst case to just 48 kB, a 250x reduction. I've been doing work on the database/storage/trie code. While looking at the API between the EVM and the database/storage/trie, this stack patch stood out and made itself obvious. As it's tiny, rather than more talk, here it is. Note: This patch is intentionally small, non-invasive, and hopefully easy to understand, so that it doesn't conflict with other work done on the EVM, and can easily be grafted into any other EVM structure. Motivation ========== - We run out of space and crash on some targets, unless the stack limit is raised above its default. Surprise segmentation faults are unhelpful. - Some CI targets have been disabled for months due to this. - Because usage borders on the system limits, when working on database/storage/trie/sync code (called from the EVM), segmentation faults occur and are misleading. They cause lost time due to thinking there's a crash bug in the code being worked on, when there's nothing wrong with it. - Sometimes unrelated, trivial code changes elsewhere trigger CI test failures. It looks like abrupt termination. A simple, recent patch was crashing in `make test` even though it was a trivial refactor. Turns out it pushed the stack over the edge. - A large stack has to be scanned by the Nim garbage collector sometimes. Larger stack means slower GC and memory allocation. - The structure of this small patch suggests how to weave async into the EVM with almost no changes to the EVM, and no async transformation overhead. - The patch seemed obvious when working on the API between EVM and storage. Measurements before =================== All these tests were run on Ubuntu 20.04 server, x86-64. This is one of the targets that has been disabled for a while in CI in EVMC mode due to crashing, and excessive stack usage is the cause. Testing commit 0c34a8e `2021-04-08 17:46:00 +0200 CI: use MSYS2 on Windows`. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default to avoid crash. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 38496 depthHigh 3 ... Stack range 13140272 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json These tests use 13.14 MB of stack to run, and so crash with the default stack limit on Ubuntu Server 20.04 (8MB). Exactly 12832 bytes per EVM call stack frame. It's interesting to see some stack frames take a bit more. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 15488 depthHigh 2 ... Stack range 3539312 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 3756144 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 7929968 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json These tests use 7.92MB of stack to run. About 7264 bytes per EVM call stack frame. It _only just_ avoids crashing with the default Ubuntu Server stack limit of 8 MB. However, it still crashes on Windows x86-64, which is why the CI target is currently disabled. On Linux where this passes, this is so borderline that it affects work and testing of storage and sync code, because that's called from the EVM. Which was a motivation for dealing with the stack instead of letting this linger. Also, this stack greatly exceeds the default thread stack size. $ rm -f build/all_tests && make ENABLE_EVMC=0 test $ ulimit -S -s 16384 # Requires larger stack than default to avoid crash. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 33216 depthHigh 3 ... Stack range 11338032 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json These tests use 11.33 MB stack to run, and so crash with a default stack limit of 8MB. Exactly 11072 bytes per EVM call stack frame. It's interesting to see some stack frames take a bit more. $ rm -f build/all_tests && make ENABLE_EVMC=0 test $ ulimit -S -s 16384 # Requires larger stack than default. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 10224 depthHigh 2 ... Stack range 2471760 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 2623184 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 5537824 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json These tests use 5.54 MB of stack to run, and avoid crashing on with a default stack limit of 8 MB. About 5408 bytes per EVM call stack frame. However, this is uncomfortably close to the limit, as the stack frame size is sensitive to changes in the code. Also, this stack greatly exceeds the default thread stack size. Measurements after ================== (This patch doesn't address EVMC mode, which is not our default. EVMC stack usage remains about the same. EVMC mode is addressed in another tiny patch.) $ rm -f build/all_tests && make ENABLE_EVMC=0 test $ ulimit -S -s 80 # Because we can! 80k stack. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 496 depthHigh 3 ... Stack range 49504 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json $ rm -f build/all_tests && make ENABLE_EVMC=0 test $ ulimit -S -s 72 # Because we can! 72k stack. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 448 depthHigh 2 ... Stack range 22288 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 23632 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 49504 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json For both tests, a satisfying *48 bytes* per EVM call stack frame, and EVM takes not much more than 48 kB. With other overheads, both tests run in 80 kB stack total at maximum EVM depth. We must add some headroom on this for database activity called from the EVM, and different compile targets. But it means the EVM itself is no longer a stack burden. This is much smaller than the default thread stack size on Linux (2MB), with plenty of margin. It's even smaller than Linux from a long time ago (128kB), and some small embedded C targets. (Just fyi, though, some JVM environments allocated just 32 kB to thread stacks.) This size is also well suited to running EVMs in threads, if that's useful. Subtle exception handling and `dispose` ======================================= It is important that each `snapshot` has a corresponding `dispose` in the event of an exception being raised. This code does do that, but in a subtle way. The pair of functions `execCallOrCreate` and `execCallOrCreateAux` are equivalent to the following code, where you can see `dispose` more clearly: proc execCallOrCreate*(c: Computation) = defer: c.dispose() if c.beforeExec(): return c.executeOpcodes() while not c.continuation.isNil: c.child.execCallOrCreate() c.child = nil (c.continuation)() c.executeOpcodes() c.afterExec() That works fine, but only reduces the stack used to 300-700 kB instead of 48 kB. To get lower we split the above into separate `execCallOrCreate` and `execCallOrCreateAux`. Only the outermost has `defer`, and instead of handling one level, it walks the entire `c.parent` chain calling `dispose` if needed. The inner one avoids `defer`, which greatly reduces the size of its stackframe. `c` is a `var` parameter, at each level of recursion. So the outermost proc sees the temporary changes made by all inner calls. This is why `c` is updated and the `c.parent` chain is maintained at each step. Signed-off-by: Jamie Lokier <[email protected]>
45cc106
to
8211db1
Compare
There's been a lot of talk about the Nimbus EVM "stack problem". I think we
assumed changing it would require big changes to the interpreter code, touching
a lot of functions.
It turned out to be a low hanging fruit.
This patch solves the stack problem, but hardly touches anything. The change
in EVM stack memory is from 13 MB worst case to just 48 kB, a 250x reduction.
I've been doing work on the database/storage/trie code. While looking at the
API between the EVM and the database/storage/trie, this stack patch stood out
and made itself obvious. As it's tiny, rather than more talk, here it is.
Note: This patch is intentionally small, non-invasive, and hopefully easy to
understand, so that it doesn't conflict with other work done on the EVM, and
can easily be grafted into any other EVM structure.
Motivation
We run out of space and crash on some targets, unless the stack limit is
raised above its default. Surprise segmentation faults are unhelpful.
Some CI targets have been disabled for months due to this.
Because usage borders on the system limits, when working on
database/storage/trie/sync code (called from the EVM), segmentation faults
occur and are misleading. They cause lost time due to thinking there's a
crash bug in the code being worked on, when there's nothing wrong with it.
Sometimes unrelated, trivial code changes elsewhere trigger CI test failures.
It looks like abrupt termination. A simple, recent patch was crashing in
make test
even though it was a trivial refactor. Turns out it pushed thestack over the edge.
A large stack has to be scanned by the Nim garbage collector sometimes.
Larger stack means slower GC and memory allocation.
The structure of this small patch suggests how to weave async into the EVM
with almost no changes to the EVM, and no async transformation overhead.
The patch seemed obvious when working on the API between EVM and storage.
Measurements before
All these tests were run on Ubuntu 20.04 server, x86-64. This is one of the
targets that has been disabled for a while in CI in EVMC mode due to crashing,
and excessive stack usage is the cause.
Testing commit 0c34a8e
2021-04-08 17:46:00 +0200 CI: use MSYS2 on Windows
.These tests use 13.14 MB of stack to run, and so crash with the default stack
limit on Ubuntu Server 20.04 (8MB). Exactly 12832 bytes per EVM call stack
frame. It's interesting to see some stack frames take a bit more.
These tests use 7.92MB of stack to run. About 7264 bytes per EVM call stack
frame. It only just avoids crashing with the default Ubuntu Server stack
limit of 8 MB. However, it still crashes on Windows x86-64, which is why the
CI target is currently disabled.
On Linux where this passes, this is so borderline that it affects work and
testing of storage and sync code, because that's called from the EVM. Which
was a motivation for dealing with the stack instead of letting this linger.
Also, this stack greatly exceeds the default thread stack size.
These tests use 11.33 MB stack to run, and so crash with a default stack limit
of 8MB. Exactly 11072 bytes per EVM call stack frame. It's interesting to see
some stack frames take a bit more.
These tests use 5.54 MB of stack to run, and avoid crashing on with a default
stack limit of 8 MB. About 5408 bytes per EVM call stack frame.
However, this is uncomfortably close to the limit, as the stack frame size is
sensitive to changes in the code.
Also, this stack greatly exceeds the default thread stack size.
Measurements after
(This patch doesn't address EVMC mode, which is not our default. EVMC stack
usage remains about the same. EVMC mode is addressed in another tiny patch.)
For both tests, a satisfying 48 bytes per EVM call stack frame. Both tests
run in 80 kB stack total at maximum EVM depth.
We must add some headroom on this for database activity called from the EVM,
and different compile targets. But it means the EVM itself is no longer a
stack burden.
This is much smaller than the default thread stack size on Linux (2MB), with
plenty of margin. It's even smaller than Linux from a long time ago (128kB),
and some small embedded C targets. (Just fyi, though, some JVM environments
allocated just 32 kB to thread stacks.)
This size is also well suited to running EVMs in threads, if that's useful.
Subtle exception handling and
dispose
It is important that each
snapshot
has a correspondingdispose
in the eventof an exception being raised. This code does do that, but in a subtle way.
The pair of functions
execCallOrCreate
andexecCallOrCreateAux
areequivalent to the following code, where you can see
dispose
more clearly:That works fine, but only reduces the stack used to 300-700 kB instead of 48 kB.
To get lower we split the above into separate
execCallOrCreate
andexecCallOrCreateAux
. Only the outermost hasdefer
, and instead of handlingone level, it walks the entire
c.parent
chain callingdispose
if needed.The inner one avoids
defer
, which greatly reduces the size of its stackframe.c
is avar
parameter, at each level of recursion. So the outermost procsees the temporary changes made by all inner calls. This is why
c
is updatedand the
c.parent
chain is maintained at each step.