How to understand the mechanics of Truffle

[Timothy Baldridge]

I'm evaluating Truffle for use in a language I'm developing. I've written
several interpreters (with JITs) in RPython in the past, so I'm familiar
with the concepts involved. I've also read quite a few papers on Truffle
and the differences between it and RPython.

However, I have a few questions, these are things that are still vague in
my mind even after reading the literature available on Truffle:

1) When does Truffle start the merging of AST nodes into compiled code? Is
this demarcation specified by the programmer, or by a profiler in Truffle?
Is there a way for the programmer to influence these mechanics?

2) How much of a given AST is compiled into a single code unit by Truffle?
How is that controlled?

3) Does Truffle search an AST graph via partial execution, or by reflection
(by walking all fields on nodes that are marked with @Node annotations?).
What is the point of the annotations for Nodes and Node children, is it
purely programmer convenience or does it tie into the JIT?

4) The literature states that a requirement for a Truffle interpreter is
that the AST should stabilize at some point in order to not require
continual re-compilation. How does this work for code that uses generators
(like ZipPy) that use the special Control-Flow exception? Is it possible to
have a control-flow exception return an AST node that is executed by the
exception handler?

5) What is the definition of "not changing" for a AST graph? Is it that the
AST nodes should stop throwing de-optimization exceptions at some point? Is
it that the node types must change? Or is it that the actual instances of
the AST nodes must not change from one evaluation of the AST tree to the
next?

Thanks for the help, and for the great work on Truffle!

Timothy Baldridge