Hello,

I've read https://www.endoflineblog.com/graal-truffle-tutorial-part-9-performance-benchmarking and wanted to leave some feedback.
It is a nice write up, thank you for these nice blog posts.
I'm sure they help people getting started with Truffle.

I noticed a few things which are rather unexpected, based on my experience with Truffle (I work on TruffleRuby).

The first thing is the benchmark redefines the function every time.
That seems unexpected, especially for micro-benchmarks.
Here it seems much better to declare the function in the setup, and only call fib inside the benchmark itself.
Also calling eval like this is likely to have a non-trivial overhead.
Better would be to Value fib; as a field, fib = context.eval("ezs", "function fib(n) {...}") in setup and then benchmark fib.execute(20).
Another possibility would be to store "fib(20)" as a Source and pass that to eval.

The mutable FunctionObject approach feels quite off for JS-like languages. I guess the inspiration is SLFunction?
IMHO it's kind of a hack and it only works because in SL there are only functions at the top-level, and so a single map of functions conceptually, and the functions objects are used both for caching looking and holding on the CallTarget.
In a JS-like language, typically the function/property lookup would be cached separately (using the Truffle Object Model), and the function itself would have a fixed CallTarget.
Related, the caching in GlobalVarReferenceExprNode seems only correct if it's only functions that can be assigned at the top-level and not other variables. Otherwise, this would cache fib to the given function even after fib = 3 at the top-level (which cannot really be handled by the mutable FunctionObject).

The change in BlockStmtNode should not change peak performance (although it is a good change in general), Graal should compile it the same no matter which version is used, because it can see ret is unused except the last one after it exploded/unrolled the loop. Do you have a way to reproduce that? If the performance actually differs it would likely be a bug.
Possibly the difference you saw could be caused by not enough warmup.
cc @rschatz

They are stored in something called auxiliary slots; basically a map inside the VirtualFrame. The keys of that map historically were instances of a class called FrameSlot. However, that class has been removed in GraalVM version 22, and now the map is indexed by integers, the same way function arguments are. These integer indexes are related to another important class, FrameDescriptor.

Is the term "auxiliary slot" precise here? I understand the flow with descriptors and eg setObject / getObject methods in the Frame. But it also has methods with literal term "auxiliary" in them: setAuxiliarySlot / getAuxiliarySlot, which seem to be something different and unrelated to frame descriptors.