LuaJIT FFI type specialization persists after module reload — how to safely invalidate stale ctype caches

Stale FFI type specialization after reloading a LuaJIT module

I am working with LuaJIT's FFI and have run into a design question around type-specialization caching. When a module is reloaded via require (for example after redefining a C struct layout), the recorded type specialization appears to persist, so conversions may still follow the old struct layout. My understanding is that the cache key is derived from the FFI function pointer and type ID, which means a reused pointer after a library reload could silently keep the old specialization active.

The goal is a reliable way to guarantee that, after a struct redefinition or module reload, all subsequent FFI calls use the new type information rather than the cached specialization. I am also unsure whether garbage-collecting the old userdata invalidates anything, since collected objects may still trigger the cached conversion path.

Specific questions:

• Is there a documented, supported mechanism to invalidate FFI type specializations, or is ffi.flushctype() the only option despite being described as an undocumented workaround?
• Does the cache behavior differ between LuaJIT 2.0 and 2.1, and would jit.dump output confirm which specialization is active after a reload?
• Is redefining a ctype with the same name between reloads itself undefined behavior that should simply be avoided?