fix: virtualize vPool as a facet

[erights]

Virtualize vPool as a facet

Staged on #4706

Compare with #4630 , which never worked

[Chris-Hibbert]

Why can you get rid of singlePool, but not doublePool? They wrap pool.js in similar ways.

[erights]

There is a cycle between pool and singlePool (aka vPool). Creating a pool creates a vPool, and they point at each other. Following dependencies starting from pool.js I didn't encounter doublePool and so have not started thinking about how to virtualize it. What would you recommend?

[Chris-Hibbert]

Not sure.

doublePool and singlePool are polymorphic wrappers of pool. Each pool has a single long-lived singlePool. doublePools connect two pools, and are created on demand.

I don't think it works to move singlePool's methods into pool`.

I don't think it's necessary for singlePool to be part of the persistent state. It would be fine for the singlePool to be created when the pool is created or revived.

[erights]

Just to clarify, can anyone outside the vat be holding a remote reference to a singlePool? If so, are singlePools potentially high cardinality?

[Chris-Hibbert]

Unlike vaults, clients don't hold onto any state of the AMM between transactions. All requests go through the public (or creator) interface for every request.

[erights]

Excellent! Then yes, I can and should simplify this. Thanks.

[Chris-Hibbert]

Not sure.

doublePool and singlePool are polymorphic wrappers of pool. Each pool has a single long-lived singlePool. doublePools connect two pools, and are created on demand.

I don't think it works to move singlePool's methods into pool`.

I don't think it's necessary for singlePool to be part of the persistent state. It would be fine for the singlePool to be created when the pool is created or revived.

[warner]

@erights could you rebase this and force-push a new version? It looks like this branch includes slightly different forms of the ERTP virtualization that already landed. I did a trial rebasing locally and the only remaining change were in packages/run-protocol/ as expected. I'll glance at those changes, but I'll hold off on a review of the real PR until I know I'm looking at the right code.

[erights]

@erights could you rebase this and force-push a new version? It looks like this branch includes slightly different forms of the ERTP virtualization that already landed. I did a trial rebasing locally and the only remaining change were in packages/run-protocol/ as expected. I'll glance at those changes, but I'll hold off on a review of the real PR until I know I'm looking at the right code.

Done. But, given @Chris-Hibbert 's comments at #4707 (comment) I'm putting this back into draft status. Instead, it seems #4706 is closer to what we want, so I'm declaring #4706 Ready to Review. Everyone, please review that one instead.

[erights]

@FUDCo @warner Please look at https://github.com/Agoric/agoric-sdk/runs/5654712229?check_suite_focus=true
Before rebasing, this PR was green under CI. After rebasing I see

virtualObjects › virtualObjectGC › VO refcount management 3 faceted

  Difference:

  - undefined
  + {
  +   key: 'vom.rc.o+11/3',
  +   result: '1',
  +   type: 'vatstoreGet',
  + }

  › validate (packages/SwingSet/test/liveslots-helpers.js:259:7)
  › voRefcountManagementTest3 (packages/SwingSet/test/virtualObjects/test-virtualObjectGC.js:1297:3)
  › async packages/SwingSet/test/virtualObjects/test-virtualObjectGC.js:1332:3

which looks like a GC bug.

[FUDCo]

@FUDCo @warner Please look at https://github.com/Agoric/agoric-sdk/runs/5654712229?check_suite_focus=true Before rebasing, this PR was green under CI. After rebasing I see

virtualObjects › virtualObjectGC › VO refcount management 3 faceted

  Difference:

  - undefined
  + {
  +   key: 'vom.rc.o+11/3',
  +   result: '1',
  +   type: 'vatstoreGet',
  + }

  › validate (packages/SwingSet/test/liveslots-helpers.js:259:7)
  › voRefcountManagementTest3 (packages/SwingSet/test/virtualObjects/test-virtualObjectGC.js:1297:3)
  › async packages/SwingSet/test/virtualObjects/test-virtualObjectGC.js:1332:3

which looks like a GC bug.

This has to be some kind of merge error in the rebase. Don't know what it is, but something got lost in translation.

[turadg]

Done in #5187