Moving from Lua 5.4 to 5.1/JIT

[Leadwerks]

Channel Packing Tool.lua.txt

I am investigating moving our Lua integration from 5.4 to LuaJIT (5.1) because I don't feel much has been added to justify loss of the improved performance LuaJIT provides.

My application compiled with LuaJIT and ran with no problems. However, I have already uncovered two issues.

Shared Pointer Comparisons

Under some circumstances shared_ptr comparisons are returning false when they should be returning true.

    elseif event.id == EVENT_WIDGETACTION then

        local widget = Widget(event.source)
        Print(widget.text)
        Print(extension.menuitem.text)
        
        if event.source == extension.menuitem then
        
            Print("OK")-- this gets hit in Lua 5.4, does not get hit in Lua 5.1/JIT

It appears that when using LuaJIT / 5.1, shared pointer comparisons are more sensitive and have to be cast to the same type. In my code above, event.source is a shared_ptr<Object> and extension.menuitem is a shared_ptr<Widget>. The Widget class is derived from the Object class.

When I cast event.source to a shared_ptr<Widget> the code works:

    elseif event.id == EVENT_WIDGETACTION then

        local widget = Widget(event.source)
        Print(widget.text)
        Print(extension.menuitem.text)
        
        if Widget(event.source) == extension.menuitem then
        
            Print("OK")

Error Handling

I am also seeing a read access violation if I try to assign a nil value to a shared_ptr<Object> member in a structure:

event.source = nil

The following error occurs in std::_Ptr_baseUltraEngine::Object::_Incref()

Exception thrown: read access violation.
this was 0x18.

With Lua 5.4, a nice error message will be displayed, using my handling of sol's error callbacks:

stack index 3, expected userdata, received nil: value is not a userdata (bad argument into 'void(std::shared_ptr<UltraEngine::Object>)')
stack traceback:
	[C]: in metamethod 'newindex'
	[string "ultra engine\scripts\start\extensions\channel packing tool.lua"]:63: in function <[string "ultra engine\scripts\start\extensions\channel packing tool.lua"]:61>
stack index 3, expected userdata, received nil: value is not a userdata (bad argument into 'void(std::shared_ptr<UltraEngine::Object>)')
stack traceback:
	[C]: in metamethod 'newindex'
	[string "ultra engine\scripts\start\extensions\channel packing tool.lua"]:63: in function <[string "ultra engine\scripts\start\extensions\channel packing tool.lua"]:61>
Error: [string "ultra engine\scripts\start\extensions\channel packing tool.lua"]:63: in function <[string "ultra engine\scripts\start\extensions\channel packing tool.lua"]:61>

So I guess it is an error either way, but sol seems to catch it using Lua 5.4 before the code is executed.

This is how I include sol:

#define SOL_NO_CHECK_NUMBER_PRECISION 1
#define SOL_ALL_SAFETIES_ON 1
#define SOL_USING_CXX_LUAJIT 1
#define SOL_SAFE_NUMERICS 1
#define SOL_CHECK_ARGUMENTS 1
#define SOL_EXCEPTIONS_SAFE_PROPAGATION 1
#include <sol/sol.hpp>

Are there any gotchas I should be aware of in moving from Lua 5.4 to 5.1/JIT? I have attached this Lua file in case you would like to get a better idea of how it is being used.

[skhaz]

I am also interested on this.

[Leadwerks]

I think I will not pursue this because I don't really know what LuaJIT is doing, and it feels out of my control.