Allocation optimizations

[Antonio Nikishaev]

Help me to understand causes for how things work.
luajit v2.1 HEAD


-----------------------------------------
local function qux (state)
state.x = 1
state.y = state.x
end


local function main1 () -- gc
local state = {}
qux (state)
end

local function main2 () -- no gc
local state = { x=0 }
qux (state)
end

local function main3 () -- gc
local state = { }
state.x = 0
qux (state)
end

local function main4 () -- gc
local state = { x=0, z={} }
qux (state)
end




local function quux (state)
state.z = {}
end


local function main5 () -- gc
local state = {}
quux (state)
end


for i = 1, 1e7 do
main1()
end
----------------------------------------- code end



1) Are there any particular reasons for this behaviour I don't see?
2) I'm very interested in the main5 case. Any way to do it gc-free?

[Mike Pall]

Post by Antonio Nikishaev
1) Are there any particular reasons for this behaviour I don't see?

Basically, some missing optimizations for special cases. I've just
added a couple of them to the v2.1 branch of the git repository.
This makes all of your test cases allocation-free.

Post by Antonio Nikishaev
2) I'm very interested in the main5 case. Any way to do it gc-free?

The allocation of the nested table is eliminated for your simple
test case, but this is unlikely to work for real-world code. The
parent table is not actually sunk into a side exit here, which in
turn permits simple DCE of the allocation of the nested table.

It's not the sinking of recursive aggregates that's the problem.
But general unsinking (rematerialization) of recursive aggregates
is rather complicated. That's why the current implementation of
allocation sinking in LuaJIT 2.x only works on flat aggregates.

If this is in a critical piece of your code and you depend on
allocation sinking to work, then your best bet is to flatten your
data structures (BTW: FFI structs inlined in structs are ok, too).

--Mike