Supporting batching of iterators so a chunk can process in one crank

[turadg]

What is the Problem Being Solved?

Some things can't be sync because they'd be too large to process in one crank. A simple async iterator would process each item in a separate turn. We need a batching capability so that an async iterator can synchronously process a batch in one crank.

Description of the Design

TBD

Security Considerations

--

Test Plan

--

[Tartuffo]

Looks like a SwingSet feature ask, so adding SwingSet label. FYI @warner

[Tartuffo]

One example was liquidation, but if we this one at a time we don't need it. But we need to investigate if there are any other examples we would cross crank boundaries.

[mhofman]

Note: breaking up each item in a different crank involves the kernel and may ultimately become too inefficient, at which point we'll probably need a mechanism sensitive to the remaining meter value akin to requestIdleCallback's IdleDeadline, which obviously introduces a risk of code being able to sense how much computation other code in the same vat performs.

[warner]

As discussed last week:

• The core feature is a send-to-self primitive.
  • at the liveslots level, this is just syscall.send() using one of your own o+NN vrefs as a target
  • but there's not currently a way to reach it from userspace
  • back when we used bang-notation for eventual send (today's E(target).method(args) was spelled target!method(args)), I used to joke about target!!method(args) to mean "send to target but ensure that it happens in a future crank", which only really does anything different if target is in your own vat
  • these days, we could imagine E.sendInNewCrank(target).method(args)
  • but for this ticket, we don't need a general mechanism
  • p = vatPowers.yieldCrank() would be enough: it could use an internal object as the syscall.send target, and return a promise that fires in a future crank
  • putting it on vatPowers might be overkill, but feels safer than making it ambient
• with that, userspace could break work into chunks and distribute the chunks across cranks
  • however, that doesn't provide any hints about how much work should be done in each crank
  • userspace might underestimate (do only one piece per crank) and be inefficient / high-latency
  • or might overestimate (do too much) and risk meter faults
  • adapting automatically would require sharing metering information with the vat
  • as a timing-channel sensor, this should definitely be on vatPowers, and not ambient
  • (anyone who can read the meter can also deduce something about the internal execution of other code)
  • vatPowers.getRemainingMeter() (in absolute computrons, or as percentage of remaining meter)
  • then we can write a utility function spreadOverCranks(meterThreshold) that provides an async iterator which cycles as much as possible in the current crank, until the remaining meter drops below the chosen threshold, and then the next cycle doesn't start until a future crank
• having userspace be sensitive to metering would interfere with some forms of XS/xsnap upgrade
  • where we want to replay the vat transcript against a different engine (with different metering) than the one that recorded it
  • we might consider recording meter queries like syscalls, so the replay can be told to make the same metering-driven decisions as the original, even though the new engine is reporting different values
  • liveslots would process vatPowers.getRemainingMeter() like a normal syscall
  • but the supervisor would get the local (xsnap) meter value and include it in the syscall request
  • the kernel would echo the meter value back to the worker, in the syscall response
  • the kernel would record the meter in the transcript, in the syscall response too
  • so future replays would make it look like the kernel decided the meter value
  • the supervisor would receive the syscall response and pass the number back up to liveslots and userspace