Re: LuaJIT FFI __gc metamethod?

[Josh Haberman <jhaberman@...>]

Mike Pall <mikelu-1102 <at> mike.de> writes:
> Ouch! You're creating a different metatable, another table and two
> different closures for every single instance. This is rather
> wasteful.

Totally agreed, I only wrote it this way for benchmarking purposes.
Since my benchmark only created one message I didn't worry about
sharing the per-message-type overhead, but the real thing will most
certainly do this.

> Instead create the userdata from C code and keep the cdata _inside_
> the userdata. Cast the userdata to a pointer to your struct before
> using it: http://lua-users.org/lists/lua-l/2011-01/msg01282.html

That's perfect!  With that approach I can make my actual objects a
userdata (and be able to use metamethods like __gc without waiting for
LuaJIT 2.1), but still use ffi for fast read/write of the data.

> > It turns out that table lookup inside __newindex is basically free, as are
> > both of the function calls: in my benchmark calling "wrapped.a = 5" was
> > just as efficient as calling the cdata cirectly!  The generated assembly is
> > longer, but it runs at the same speed.  Amazing.
> 
> Because dead-store-elimination hits and turns your code into an
> empty loop.

Does it?  I saw this store of my value (5) in the generated code -- I know
it's my value because when I change in in my Lua program, it changes in
the disassembly also:

1390bffd6  mov dword [rax+0xc], 0x5

Do you have any comment about whether the table lookup inside my
__newindex method can be JIT-ted as well as my benchmark implied?
Is that approach inherently more expensive than a regular method call?

Josh