Tracing

[MarcelGarus]

Depends on #241

#241 changed the VM architecture a lot. In particular, it introduced the ability to run several concurrently running fibers. This broke tracing, which still relied on some assumptions such as all objects being in a single heap.

This PR fixes the tracing by moving the tracer outside of the fiber's and VM's ownership. Instead, the tracer is borrowed to the vm.run method, along with the other existing context parts passed to it. Depending on the amount of insight that the outside world wants to get into the execution, it can pass in different tracers. The following tracers exist for now:

• Dummy tracer: Saves nothing.
• Fuzzable closures finder: Only tracks all found fuzzable closures.
• Full tracer: Saves every single event that occurs.

We can use the full tracer to figure out exactly what happened in the VM. Using this, we can correctly output which part of the code is responsible and we have nice stack traces, even across fibers.

core = use "..Core"

main environment :=
  print message = { core.channel.send environment.stdout message }
  print "Hello, world!"

  core.parallel { nursery ->
    print (core.await (core.async nursery {
      print "Hello from fiber!"
      "Hello, async await!"
    }))

    core.async nursery { print "Kiwi" }
    core.async nursery { core.panic "life's not fair" }
    print "Hi"
  }

Previously, we also supported a hierarchical trace dump that related calls to returns, etc. For now, in the new architecture, we only have a straightforward list of all events. However, I plan on introducing a Flamegraph-inspired graphical trace visualization that looks something like this:

This would allow us to do profiling of the Candy code itself and also see dependencies between fibers.