caching marshaller

[turadg]

What is the Problem Being Solved?

Contracts that write to vstorage with board values (e.g. using agoricNames) have to make a remote call to the board vat to get CapData they can stringify for writing to vstorage.

Reducing the trips is explored in #6646 but this issue is about the problem of using a remote marshaller that has to make a remote call even if all the necessary remote data has made it to the source vat.

Description of the Design

A local caching marshaller that only calls out to the board vat for object identities it doesn't have yet.

No need to evict cache because a board slot is forever a particular object identity.

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[dtribble]

Is the cache weak or strong? Having a bounded cache avoids storage leak in contracts in strong caches. An LRU with justa. few entries could prevent large numbers of re-lookups of the same Brand, for example.

[mhofman]

Contract code doesn't get to use weakref so the only implementation for a weak LRU I can think of would involve a list of weakmap instances, which requires lookups in n WeakMap instances, which is potentially expensive, especially because we can't reuse the WM instances, which has associated gc cost being virtual aware weak maps.