JIT Infrastructure for continuation serialization

[dolio]

This PR includes work that goes part of the way toward having serializable continuations on the JIT.

One of the main changes is a rework of the define-unison macro. It now has additional features and expands to different code.

• The definition with the primary name is now a macro, so static occurrences of ref-whatever have the following behavior
  • Occurrences in a non-function context just build a closure
  • Under-applications also expand to building a closure
  • Exactly saturated applications expand to the fast path
  • Over-applications split the argument list
• The above means that occurrences of a unison function are never raw scheme procedures. Saturated applications directly call the procedure, and under-applications are always a closure structure. This means the 'slow path' was able to be moved into a procedure property of the closure struct. When you use a closure as a function, it is the slow path.
• The macro now takes 'hints' that control its behavior.
  • 'force-pure makes the macro generate code under the assumption that the continuation will never be captured and serialized, so annotations do not have to be manipulated. This performs better.
  • 'gen-link makes the macro generate a builtin termlink for the definition
  • 'no-link-decl tells the macro to not declare the association between the generated function and the termlink. Otherwise the macro automatically handles this, and it is no longer necessary to do by hand
  • 'internal bundles together some of the above options as appropriate for internal, builtin definitions
• A helper macro define-unison-builtin has been made for defining builtin definitions. It picks hints that are appropriate for such definitions.
• The generated code also has some features for detecting when it's in an ability context that would not involve serializing a continuation (like, just IO and Exception), allowing it to skip annotating the continuation there, too. This works via a runtime test, but as with arithmetic on small numbers, this seems to have negligible cost when you are actually in a context that is supposed to be fast.

The checked in files have been modified with this in mind, and the bumped share code generates appropriate output. Right now, 'force-pure defaults to #t, because reflecting the continuation isn't actually implemented yet. So there should be no performance impact at the moment (it's equivalent to the old code).

This also declares some structures for continuation management. There is a structure for wrapping a racket continuation, and another for a representation in terms of (de)serialized frames. Conversion between the two is as needed; for instance, it doesn't make sense to immediately reflect the continuation into serializable frames if it's just going to be used locally. Code for deserializing into the frame representation has been implemented in the two repositories, but some of the cases for actually applying a continuation are missing, pending some supporting work from the code generator.

[aryairani]

Awesome!
What's the slow path? The one that supports restoring a serialized continuation?

[dolio]

No, the slow path is what happens when you call a function that gets passed as an argument. Since that could be anything, you need to inspect it and look at how many arguments it takes vs. how many you're applying and so on. For statically known functions you can figure that out at compile time so all you have to do at runtime is jump to the code (or whatever).