-
-
Notifications
You must be signed in to change notification settings - Fork 289
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
feat: regen to consume state cache reload api #6456
Conversation
Performance Report✔️ no performance regression detected 🚀🚀 Significant benchmark improvement detected
Full benchmark results
|
} | ||
|
||
/** | ||
* Get state after block `blockRoot` dialed forward to `slot` | ||
* - shouldReload should be used with care, as it will cause the state to be reloaded from disk |
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.
Do you think it is better to rename shouldReload
to shouldReloadFromDisk
to emphasize and warn about the consequence of setting this flag to true?
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'm open to change, cc @wemeetagain for your preference
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 think that is a good suggestion. shouldReloadFromDisk
is more descriptive and expressive
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.
or allowDiskReload
?
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.
yes allowDiskReload
really matches the usage of this flag 👍
@@ -77,20 +84,23 @@ export class StateRegenerator implements IStateRegeneratorInternal { | |||
async getCheckpointState( | |||
cp: phase0.Checkpoint, | |||
opts: StateCloneOpts, | |||
rCaller: RegenCaller | |||
rCaller: RegenCaller, | |||
shouldReload = false |
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.
should this flag move in StateCloneOpts?
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.
shouldReload
is designed to use within this file only, I don't want to publish shouldReload
flag to all consumers, it should only be true
when we get state for block processing, or updateHeadState
. It's easier to control it within this file
*/ | ||
async getBlockSlotState( | ||
blockRoot: RootHex, | ||
slot: Slot, | ||
opts: StateCloneOpts, | ||
rCaller: RegenCaller | ||
rCaller: RegenCaller, | ||
shouldReload = false |
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.
may be can move in StateCloneOpts here as well?
} | ||
|
||
/** | ||
* Get state after block `blockRoot` dialed forward to `slot` | ||
* - shouldReload should be used with care, as it will cause the state to be reloaded from disk |
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 think that is a good suggestion. shouldReloadFromDisk
is more descriptive and expressive
const checkpointState = postState; | ||
const cp = getCheckpointFromState(checkpointState); | ||
checkpointStateCache.add(cp, checkpointState); | ||
emitter.emit(ChainEvent.checkpoint, cp, checkpointState); | ||
emitter.emit(ChainEvent.checkpoint, cp, checkpointState.clone()); |
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.
Why add the costly clone()
here?
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.
- if downstream event handlers mutate the state mistakenly, it does not affect our cache
clone()
is really cheap and that's awesome feature of our tree backed state, see https://github.com/ChainSafe/ssz/blob/6220d320b004ea80bd30925487ac0f3299295528/packages/persistent-merkle-tree/src/tree.ts#L80
in fact I will add more clone()
when returning an item from cache to avoid this mistake, see #6178 (comment)
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6456 +/- ##
============================================
+ Coverage 61.63% 61.69% +0.05%
============================================
Files 553 555 +2
Lines 57975 58253 +278
Branches 1832 1844 +12
============================================
+ Hits 35733 35937 +204
- Misses 22205 22277 +72
- Partials 37 39 +2 |
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.
seems to have addressed all concerns lgtm
🎉 This PR is included in v1.17.0 🎉 |
Motivation
getPreState
api), we want to reload state if neededDescription
INVALID_STATE_ROOT
error during regen and add logsthis is cherry-picked from #6359, it does not affect production code because we haven't configured new state caches yet,
getOrReload*
is just the same toget*
part of #5968