On Fri, Sep 17, 2010 at 9:28 PM, Mike Pall
<mikelu-1009@mike.de> wrote:
Erik Lindroos wrote:
> In order to use tracing for my own library functions, I put them inside
> LuaJIT 2 just like the built-in modules. This worked great for a while, but
> now I've hit the 256 fast function limit. I noticed even pure C functions
> without tracing use up FFIDs and avoiding that could be a way out.
Well, the functions which are not traced yet still need an ID.
This allows showing their name when a trace aborts.
Yeah, I realize this is the case for built-in modules. I meant purely for my own extensions, not anything to do in general.
I could of course just register the normal C functions the usual way with luaL_register and the traced ones with LJLIB_CF, LJ_LIB_REG etc.. I don't think the traced functions alone will overflow the ffid.
These IDs are destined only for the public functions provided by
the VM itself. I don't think I'll ever need more than 256 of them
(famous last words). Actually their total number should go down in
the long term, since the FFI would obsolete jit.util.*.
> I know you're planning on implementing a foreign function interface so I
> wonder if you had any ideas about how a general solution would look? For
> example, do you think increasing the size of the ffid field would affect
> performance a lot?
That field is carefully aligned, so please don't change it.
I noticed :).
You could do what I've done in LuaJIT 1.x: create a map from the
closure id to the function id (or a recording handler function).
In your case it might be easier to simply look up the function
pointer in the LuaL_Reg[] array to get its index (lookup speed is
not that critical here).
Umm, what are your C functions doing that can't be done in pure
Lua? Only calling low-level C functions or more? This would be
useful feedback for the design of the FFI.
The traced functions right now are mostly for low-level I/O, a PRNG, interaction with C++ libraries, for example getters/setters for C++ objects. They mostly involve calling C functions with some NULL and I/O error guards. Nothing fancy really. A lot could probably be done on the Lua side if it had efficient byte buffers (sequential read/write mostly) and ways to reliably access a userdata field from both Lua and C/C++.
/Erik
