-
Notifications
You must be signed in to change notification settings - Fork 139
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
Clean up left over Bytecode code + some related testing fixes #2607
base: main
Are you sure you want to change the base?
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @andresilva91 and the rest of your teammates on Graphite |
9160f86
to
e80bfec
Compare
546edf9
to
bbb80da
Compare
bbb80da
to
2644244
Compare
@@ -366,6 +366,7 @@ pub struct ChainRuntimeContext<S> { | |||
execution_runtime_config: ExecutionRuntimeConfig, | |||
user_contracts: Arc<DashMap<UserApplicationId, UserContractCode>>, | |||
user_services: Arc<DashMap<UserApplicationId, UserServiceCode>>, | |||
blobs: Arc<DashMap<BlobId, Blob>>, |
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.
ChainRuntimeContext
s can now remain in memory for a long time, and for any number of blocks. For the contracts and services it makes sense to keep them in memory, because an application that has been used on a chain (e.g. non-fungible
) it's likely that it will be used again.
But for other—potentially large—blobs (e.g. NFT data!) it's often the case that they get only used once (maybe the NFT is traded on this chain and moves elsewhere). In that case, we shouldn't keep the blob in memory indefinitely.
Motivation
Proposal
Fix those and properly mimic what we're doing with user contract/service code with blobs.
Test Plan
CI
Release Plan