-
Notifications
You must be signed in to change notification settings - Fork 0
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
chore: Update to upstream 3.8.7 #9
Conversation
Open Source drop, Apr 20, 2023
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.
ok, looks like the changes I was expecting
if (the->keyDelta > 0) { | ||
txID keyDelta = (theCount > the->keyDelta) ? theCount : the->keyDelta; | ||
txID keyCount = (the->keyCount + keyDelta) - the->keyOffset; | ||
txSlot** keyArray = c_realloc(the->keyArray, keyCount * sizeof(txSlot*)); |
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.
Note for the future: this uses c_realloc()
directly, unlike slots/chunks which go through an intermediate fxAllocateChunks
/fxAllocateSlots
, which xsnapPlatform.c
overrides to track in the space meter. So the space used by keys won't be tracked.
This keyArray
wants to use re-alloc, which is not quite as easy to wrap/track. But when we start trying to meter space allocation in earnest, we should consider creating an fxReallocKeys()
, which can be controlled by the platform, and which can compare the old size (i.e. it can somehow learn the old size, maybe it should accept a third arg with the old size, maybe the->keyCount
?) and new size, and apply the difference to the meter.
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.
Good call! Where should we track this?
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.
@@ -1545,6 +1527,120 @@ txSlot* fxUnprojectSlot(txMachine* the, txSnapshot* snapshot, txSlot* slot) | |||
return slot; | |||
} | |||
|
|||
int fxUseSnapshot(txMachine* the, txSnapshot* snapshot) |
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.
Right, this must take a snapshot in RAM, and initializes a (blank) txMachine
struct with the contents, for the "create new machine from the old one but within the same process" operation.
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.
No the txSnapshot
is basically the wrapper around the FILE
struct that fxSnapshotRead
uses in xsnap-worker.c
so it basically wants to read back from disk. We could implement it otherwise by also storing the snapshot in memory, but that's require temporary allocation.
size = htonl(size); | ||
mxThrowIf((*snapshot->write)(snapshot->stream, &size, 4)); | ||
mxThrowIf((*snapshot->write)(snapshot->stream, "CREA", 4)); | ||
mxThrowIf((*snapshot->write)(snapshot->stream, &creation, sizeof(txCreation))); | ||
mxThrowIf((*snapshot->write)(snapshot->stream, &(the->profileID), sizeof(txID))); | ||
mxThrowIf((*snapshot->write)(snapshot->stream, &(the->tag), sizeof(txInteger))); |
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.
note to self: this is a snapshot compatibility break: the new snapshot needs to include space for both incrementalKeyCount
and the->tag
(which is really the number of keys currently allocated).
I realized I shouldn't have created this branch at the exact commit of |
oh, yeah, that graph is a bit gross. Oh well. |
Clean merge of tag
3.8.7
Refs: Agoric/agoric-sdk#7083