How does LuaJIT's trace compiler work?
- From: Robin Heggelund Hansen <skinneyz89@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 29 Nov 2013 11:20:43 +0100
Originally posted this on stackoverflow, should probably posted it here
first:
http://stackoverflow.com/questions/20266523/how-does-luajits-trace-compiler-work
I've been reading up on JIT's and LuaJIT's trace compiler in particular,
and I ended up with some questions.
From what I understand, LuaJIT's JIT doesn't compile hot methods like
Java's HotSpot does, it compiles hot paths originating from loops. Does
this mean that if something doesn't originate from a loop (say, I call Lua
functions from the C-api) then the code will never be jitted? And what
happens when you hit another loop? Will the path to the second loop be
JIT'ed, and then a new path from that loop jitted as well, or will the
second loop be a part of the same path?
How does the interpreter choose the most optimal hot path? Let's say I have
a hash-table of ints -> strings. Now imagine that I've called table[x] with
x being 3 and 5 enough times that they've become hot paths and jitted, how
does the interpreter decide which jitted code to call for table[x] where x
is 4?
Another thing that has been racking my brain. Since paths are compiled, not
functions, won't a trace compiler require more memory? Since you can't
really re-use compiled code of another path I mean, and since paths will
probably be larger than single functions in the general case...
I'm sorry if these questions have already been addressed elsewhere!
Other related posts:
