urbit / pm

Core Development project management
9 stars 0 forks source link

core architecture notes, ~2024.4.10 #16

Open belisarius222 opened 3 months ago

belisarius222 commented 3 months ago

Today we discussed ~ritpub-sipsyl's %wild hint proposal (UIP-0122) for switching jet registrations from stateful to lexically scoped. This has unanimous support among core devs, and we are excited to start work on it.

Without this proposal, Nock interpreters have had to persist "cold jet state" (which cores are jetted, with which labels, and what subject template must be matched) indefinitely in order to correctly match jets when running Nock. This has caused numerous problems in multiple layers of the stack. "Pill" bootloaders and "portable" snapshots have had to include a separate entry for jet registrations. Arvo has to lazily build vanes, holding onto thunks -- Ford would need to do the same in order to have portable Ford caches, making the Ford cache injection quickboot strategy much more difficult. This is to say nothing of the difficulties stateful jet registration has caused for interpreter writers, for whom it posed another set of problems with which I am less familiar.

But the worst problem in my opinion is that the statefulness of the registrations damaged the conceptual purity of Nock as something that can be run without any context. A truly solid-state interpreter should be able to execute a Nock expression without needing to have loaded something special into its state beforehand. This proposal fixes this.

This proposal addresses the statefulness in an elegant way, by making jet registrations lexically scoped, declared explicitly in a Nock hint. Something else nice about this is that it only requires redoing the "cold jet state lifecycle, but the rest of the jet-related machinery in runtimes (both Vere and Ares) can remain essentially unchanged, minimizing the amount of work required to integrate it.

There was consensus among core devs that writing the Hoon piece of this proposal will be tricky and should be done first. The riskiest part of the proposal is that it requires adding and tuning some caches, so there is some possibility that those caches could be hard to tune in such a way that they get a high enough hit rate without using too much memory.

There was also consensus that the best way to validate the proposal is by trying to build it. The rough sequence of steps to implement this proposal are as follows:

  1. Write the Hoon function to extract a $wilt from a $type.
  2. Implement the ~. rune.
  3. Add something to Arvo (either an arm or a scry endpoint) to get the $wilt for the "outer context", for use in runtime functions that slam wished gates.
  4. Modify the Hoon compiler to populate core types with jet labels when encountering the ~% rune.
  5. Build interpreter machinery to use the $wilt as cold jet state.
  6. Make sure lifecycles and caches are correct and performant.