Re: LuaJIT 2 fast function limit

[Mike Pall <mikelu-1009@...>]

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.

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.

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.

--Mike