LuaJIT 2 ffi (casting / force hotpath)

[CrazyButcher <crazybutcher@...>]

excellent work Mike!

just gave the new ffi functionality a quick spin as the dll loading
mechanism seems to have its core functionality for a couple days now.

http://crazybutcher.luxinia.de/wip/luajit_ffi_ogl.gif (yeah I mistyped
some stuff in there hehe)

Now some questions:

blubb_data = ffi.new("blubb")
blah_data = ffi.cast("blah*",blubb_data)
works fine, does the object returned also reference (in GC sense) the
ffi object it originated from (blubb_data)? Or is the returned object
just a pointer, and only objects created by ffi.new have GC to cleanup
memory.

The jit would optimize away the safety checks and table lookups if I
call some dll function always in the same manner

"ogl32.glClear(...)" or would it still be favorable to store functions locally?

local clr = ogl32.glClear
function oftenCalled()
  ...
  clr(...)
  ...
end

Given the 2008 roadmap description of LuaJIT 2[1]
- constant folding could not apply, as ogl32 is just a table, hence
the "upvalue" case would be favorable
-  On the other hand guard-moving would result into upvalue like code...

You also wrote that there is a trace-tree, so "hot switches/branches"
would result into dedicated trace paths... basically all that means
there is not really much left the user would have to manually do, to
get optimal results?

Is there a way to "pre-define" a hotpath. Say I want no delays due to
runtime compilation at a later time, but as I have the knowledge of
the hotpath I want to trigger the compilation for it manually?

say that I know the first time the function is called, I want to force
it "over the threshold" to do the trace record and so on. That way the
first "frame" would take a bit longer, but the others would be faster.

- Christoph

[1] http://lua-users.org/lists/lua-l/2008-02/msg00051.html