How to profile and optimize code that runs interpreted? about raptorjit

[javierguerragiraldez]

another source of "interpreterness" is too much type unpredictability. for example, if you iterate over an array of values (with ipairs()) but you never know the type of the values there, it might get blacklisted too.

btw, record the TRACE/abort event

[lukego]

@javierguerragiraldez I'm thinking about this now in the context of the optimization guide (#68). How do we make a profiler that tells you the information you need to eliminate use of the interpreter?

I'm thinking the profiler will use three inputs:

1. Trace aborts showing each failed attempt to JIT some code.
2. Blacklistings showing the starting points where traces persistently aborted.
3. Profiler samples saying how "hot" each blacklisted bytecode is.

Then the profiler will tell you how hot each blacklisted bytecode is (mostly whole functions and loops) and then it can cross-reference this with the trace aborts to see why that bytecode was blacklisted (e.g. it leads to an NYI instruction, or to another blacklisted bytecode, etc.)

On the VM side I think we only need one extension which is for VMProfile to count separately for each blacklisted bytecode. I wonder how? The simplest idea I can think of is for the Lua VM state to include a new field that is the program counter address for the most recently executed ILOOP/IFUNC/etc i.e. the most recently entered blacklisted code. Seems like this would likely work. On the other hand to really count properly you might need to maintain stack discipline on that e.g. when calling a blacklisted loop from inside a blacklisted function, etc...

Thoughts?