tvl-depot/tvix
Vincent Ambo 025c67bf4d refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.

This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).

The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.

To do this, massive changes have occured basically everywhere in the
code. On a high-level:

1. The VM is now organised around a frame stack. A frame is either a
   call frame (execution of Tvix bytecode) or a generator frame (a
   running or suspended generator).

   The VM has an outer loop that pops a frame off the frame stack, and
   then enters an inner loop either driving the execution of the
   bytecode or the execution of a generator.

   Both types of frames have several branches that can result in the
   frame re-enqueuing itself, and enqueuing some other work (in the
   form of a different frame) on top of itself. The VM will eventually
   resume the frame when everything "above" it has been suspended.

   In this way, the VM's new frame stack takes over much of the work
   that was previously achieved by recursion.

2. All methods previously taking a VM have been refactored into async
   functions that instead emit/receive generator messages for
   communication with the VM.

   Notably, this includes *all* builtins.

This has had some other effects:

- Some test have been removed or commented out, either because they
  tested code that was mostly already dead (nix_eq) or because they
  now require generator scaffolding which we do not have in place for
  tests (yet).

- Because generator functions are technically async (though no async
  IO is involved), we lose the ability to use much of the Rust
  standard library e.g. in builtins. This has led to many algorithms
  being unrolled into iterative versions instead of iterator
  combinations, and things like sorting had to be implemented from scratch.

- Many call sites that previously saw a `Result<..., ErrorKind>`
  bubble up now only see the result value, as the error handling is
  encapsulated within the generator loop.

  This reduces number of places inside of builtin implementations
  where error context can be attached to calls that can fail.
  Currently what we gain in this tradeoff is significantly more
  detailed span information (which we still need to bubble up, this
  commit does not change the error display).

  We'll need to do some analysis later of how useful the errors turn
  out to be and potentially introduce some methods for attaching
  context to a generator frame again.

This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.

Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-03-13 20:30:59 +00:00
..
.vscode chore(tvix): fix vscode rust-analyzer recommendation 2022-10-15 16:54:28 +00:00
cli refactor(tvix/eval): flatten call stack of VM using generators 2023-03-13 20:30:59 +00:00
docs docs(tvix): fix minor spelling problems in pointer equality document 2023-01-25 14:30:50 +00:00
eval refactor(tvix/eval): flatten call stack of VM using generators 2023-03-13 20:30:59 +00:00
nix-compat feat(tvix/nix-compat/derivation): make use of NixPath in some places 2023-03-04 12:26:00 +00:00
nix_cli chore(tvix): upgrade to clap 4.0 2022-12-21 13:23:38 +00:00
proto chore(tvix/store): move castore.proto 2022-12-04 10:41:39 +00:00
serde refactor(tvix/serde): allow dead_code in struct 2023-01-31 15:35:46 +00:00
store feat(tvix/store): drop BlobWriter 2023-03-13 10:05:21 +00:00
verify-lang-tests test(tvix/eval): add test for builtins parity 2023-01-06 12:00:38 +00:00
.gitignore feat(tvix/): .gitignore target folders 2022-11-11 19:55:12 +00:00
Cargo.lock refactor(tvix/store): use read_all_and_chunk in gRPC blobservice 2023-03-13 10:05:21 +00:00
Cargo.nix refactor(tvix/store): use read_all_and_chunk in gRPC blobservice 2023-03-13 10:05:21 +00:00
Cargo.toml refactor(tvix/nix-compat): absorb nar writer 2023-01-31 15:18:39 +00:00
crate-hashes.json fix(tvix/cli): use tvlfyi/wu-manber fork for refscanner 2023-02-04 12:44:59 +00:00
default.nix fix(tvix): add dummy target to attach extra-step to 2023-02-01 17:34:08 +00:00
LICENSE chore(tvix): Bootstrap Tvix folder 2021-03-27 00:09:49 +00:00
OWNERS chore(gerrit): migrate OWNERS files to code-owners style 2022-09-19 11:13:28 +00:00
README.md docs(tvix): move mg shell command into one line 2023-02-03 12:07:07 +00:00

Tvix

Tvix is a new implementation of the Nix language and package manager. See the announcement post for information about the background of this project.

Tvix is developed by TVL in our monorepo, the depot, at //tvix. Code reviews take place on Gerrit, bugs are filed in our issue tracker.

For more information about Tvix, feel free to reach out. We are interested in people who would like to help us review designs, brainstorm and describe requirements that we may not yet have considered.

Most of the discussion around development happens on our IRC channel, which you can join in several ways documented on tvl.fyi, or on our mailing list.

Contributions to Tvix follow the TVL review flow and contribution guidelines.

WARNING: Tvix is not ready for use in production. None of our current APIs should be considered stable in any way.

WARNING: Any other instances of this project or repository are josh-mirrors. We do not accept code contributions or issues outside of the tooling and communication methods outlined above.

Components

This folder contains the following components:

  • //tvix/eval - an implementation of the Nix programming language
  • //tvix/nix-compat - library functions for compatibility with C++ Nix
  • //tvix/cli - preliminary REPL & CLI implementation for Tvix
  • //tvix/serde - Rust library for using the Nix language for app configuration
  • //tvix/store - implementation of a file store for Tvix

Some additional folders with auxiliary things exist and can be explored at your leisure.

Building the CLI

The CLI can also be built with standard Rust tooling (i.e. cargo build), as long as you are in a shell with the right dependencies.

  • If you cloned the full monorepo, it can be provided by mg shell //tvix:shell.
  • If you cloned the tvix workspace only (git clone https://code.tvl.fyi/depot.git:workspace=views/tvix.git), nix-shell provides it.

If you're in the TVL monorepo, you can also run mg build //tvix/cli (or mg build from inside that folder) for a more incremental build.

Please follow the depot-wide instructions on how to get mg and use the depot tooling.

Compatibility

Important note: We only use and test Nix builds of our software against Nix 2.3. There are a variety of bugs and subtle problems in newer Nix versions which we do not have the bandwidth to address, builds in newer Nix versions may or may not work.

Rust projects, crate2nix

Some parts of Tvix are written in Rust. To simplify the dependency management on the Nix side of these builds, we use crate2nix in a single Rust workspace in //tvix to maintain the Nix build configuration.

When making changes to Cargo dependency configuration in any of the Rust projects under //tvix, be sure to run mg run //tvix:crate2nixGenerate -- in //tvix itself and commit the changes to the generated Cargo.nix file. This only applies to the full TVL checkout.

License structure

All code implemented for Tvix is licensed under the GPL-3.0, with the exception of the protocol buffer definitions used for communication between services which are available under a more permissive license (MIT).

The idea behind this structure is that any direct usage of our code (e.g. linking to it, embedding the evaluator, etc.) will fall under the terms of the GPL3, but users are free to implement their own components speaking these protocols under the terms of the MIT license.