refactor: add passStyleOf to VatData global

[erights]

See endojs/endo#1676

#9431 currently staged on this PR

Harmless for now. Eventually to be picked up by @endo/pass-style as imported after liveslots, so it will use the one from liveslots. This makes the determinism of user code depend on passStyleOf really being deterministic. Otherwise, user code could observe GC.

[mhofman]

I still have concerns about using VatData to plumb powers from agoric-sdk into the endo layers, as I raised in endojs/endo#1676 (comment)

I actually do like @gibson042's suggestion in endojs/endo#1676 (comment) to use a registered symbol.

[erights]

I actually do like @gibson042's suggestion in endojs/endo#1676 (comment) to use a registered symbol.

Reviewers,
Could we agree on exactly that suggestion?

If so, we can deal with the inter-repo version skew issue as follows:

This PR place passStyleOf in both places for now, but mark the VatData placement as deprecated. We should get the full performance benefit at this step. The further steps below should have no further effect.

An Endo PR look for passStyleOf in both places, marking the VatData placement as deprecated.

Endo release / agoric-sdk upgrade ritual

agoric-sdk PR that stops putting it into VatData.

and endo PR that stops looking for it in VatData.

[mhofman]

I actually do like @gibson042's suggestion in endojs/endo#1676 (comment) to use a registered symbol.

Reviewers, Could we agree on exactly that suggestion?

If so, we can deal with the inter-repo version skew issue as follows:

Ok I refreshed my mind on this topic. Let's do the registered symbol approach.

I however do not understand the need for the migration dance. Why do we need agoric-sdk to place it in both places? Let's just have agoric-sdk place it with the registered symbol, and update endo to only look there. I don't believe there's been any actual use of the VatData location, and at the next Endo sync, it'll just start working.

[erights]

Let's do the registered symbol approach.

Excellent!

I however do not understand the need for the migration dance.

So we can get the benefit before the next Endo sync.

[erights]

Based on a private conversation with @kriskowal (thanks!), I'm satisfied we can do the endo+agoric-sdk versioning dance fast enough that I should just remove the VatData option from endo, and from this PR.

[erights]

In light of endojs/endo#1794 I’m trying to figure out how VatData gets from liveslots onto the relevant globals. That journey landed me at

https://github.com/endojs/endo/blob/52aba3137cb60204bcfc2af54393edef9cb65b96/packages/import-bundle/src/compartment-wrapper.js#L45

where an Object.keys will skip symbol-named properties. But I don’t know whether this code is actually relevant anyway. Help?

[mhofman]

As mentioned in Slack, my understanding is that:

• Liveslots is passing VatData in vatGlobals to buildVatNamespace:

  agoric-sdk/packages/swingset-liveslots/src/liveslots.js

  Lines 1440 to 1443 in 4ffd2ad

  	const vatNS = await buildVatNamespace(
  	vatGlobals,
  	inescapableGlobalProperties,
  	);

• vatGlobals is passed as endowments, not as inescapableGlobalProperties
• endowments end up going to the Compartment constructor, and are simply assigned to the globalObject, which supports symbols: https://github.com/endojs/endo/blob/52aba3137cb60204bcfc2af54393edef9cb65b96/packages/ses/src/compartment.js#L270

So it should work out of the box? Is it failing to appear in the compartment created by liveslots, or were you trying to propagate automatically to any nested compartment (e.g. to avoid having to modify ZCF as well, and how is ZCF handling VatData today?). Arguably the inescapable properties should propagate both symbol and string keys.

[erights]

Closing in favor of recent changes