-
Notifications
You must be signed in to change notification settings - Fork 212
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
fix: virtualize pool #4706
fix: virtualize pool #4706
Conversation
I'm expecting to see a test demonstrating that objects can be defined, saved, flushed from memory, and restored with behavior identical to the original. Is there a reason that's not appropriate here? |
3e0e502
to
72cfb21
Compare
fed23b2
to
7164f83
Compare
1592e43
to
2cfe4a3
Compare
At #4706 (comment) @Chris-Hibbert asks:
@FUDCo , should this PR test that? If so, how? Thanks. |
a4fb604
to
a68c837
Compare
2cfe4a3
to
8d7d290
Compare
Given @Chris-Hibbert 's comments at #4707 (comment) I put #4707 into draft status. Instead, it seems this PR #4706 is closer to what we want, so I'm declaring #4706 Ready to Review. Everyone, please review this one instead. |
Changed my mind again. Back to Draft until @Chris-Hibbert and I pair on this and it becomes ready. No need for others to review before then. |
We don't have a way to exercise that until #1848 / #4382 is done and we can upgrade vats. We've got test coverage on durable objects/collections in general via Although.. I suppose if you had a swingset-based test in which the virtual/durable collections were used to create some objects in vat A, then you carefully drop all references to them from RAM (leaving only exports and/or refs from virtualized data), then you wait a crank or two, then send a message back into vat A that references those objects.. that would exercise the code that rebuilds the objects from saved data. The tricky part is knowing that the original objects really got GCed, which userspace doesn't get to see. You could add some temporary debug messages to liveslots.js while testing the test, to convince yourself that GC is really happening. Running the workers under XS ( |
I was more interested in virtualization than durability. Can we page objects out and back in at this point? |
liquidityValueIn, | ||
), | ||
); | ||
const makePool = defineKind( |
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.
is the best documentation on defineKind
the comment on defineKindInternal
in virtualObjectManager.js
? The parameter types don't seem to be declared in a way that's visible to VSCode and WebStorm, so I always have to find the docs before I can tell what arguments should be provided in what order.
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.
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.
This looks fine and straightforward. I asked one question about how makeKind
works.
Do we have the ability to demonstrate that virtualization can handle paging objects out and back in again?
I've asked before and it seems like the responses have assumed I was asking about durability and revival of the contract rather than the pool objects.
); | ||
const makePool = defineKind( | ||
'pool', | ||
(liquidityZcfMint, poolSeat, secondaryBrand) => { |
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 trying to understand defineKind
. How does it know what parameters to provide to the init
function? (i.e. If the pool doesn't declare them somewhere, what rules produce the parameters?)
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.
defineKind
doesn't "know" the parameters to init
. The maker function calls init
with whatever parameters it was given.
|
||
/** @type {XYKPool} */ | ||
const pool = { | ||
getLiquiditySupply: () => state.liqTokenSupply, |
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 is liqTokenSupply
access through state
, but liquidityIsuser
, poolSeat
, updater
, etc. (line 126) are extracted and accessed as top-level values?
I don't think it should have to be the responsibility of users of the virtual object system to write tests to verify that the virtual object system works as advertised. The virtual objects implementation itself does have tests for that though. |
I'm willing to accept that it works as advertised. As a reviewer of a conversion, I'm trying to gain confidence that the right state has been captured. I'd feel a lot more confident if I saw that objects that had been paged out and in behaved the same as before. Without that I have to have confidence that I've identified all the state that is in use, and that I understand how the parts of makeKind interact in great detail. |
Ah, I misunderstood the intent of what you were trying to get at. That makes a lot of sense and seems like a thing that's genuinely important to verify. |
Is there a way to verify that? Should this PR do so? How? |
Done in #5187 |
Virtualize pool. Unlike #4707, this one does not virtualize vpool (the single pool) because it seems that the vpool need not be made persistent.
See #4707 (comment)
Note to reviewers: I may still be confused. I suspect that @Chris-Hibbert and I need to pair program this before it is good.