search

openresty / luajit2

OpenResty's Branch of LuaJIT 2
https://luajit.org/luajit.html
Other
1.24k stars 200 forks source link

Merge LuaJIT/LuaJIT/v2.1 with v2.1-agentzh #104

Closed siddhesh closed 4 years ago

siddhesh commented 4 years ago

This is an initial merge of the LuaJIT/LuaJIT v2.1 branch into luajit2/v2.1-agentzh. This should bring in all of the bug fixes that were made in LuaJIT/LuaJIT. Some notes on the merge:

jit.prngstate

jit.prngstate now takes (and returns) an array of 8 32-bit integers since the PRNG state has expanded in LuaJIT/LuaJIT.

Regressions

The fixes for LuaJIT/LuaJIT#603 cause a regression in stackov.lua in luajit2-test-suite because a stack overflow prints error in error handling instead of stack overflow. I haven't been able to figure out a fix (looks like a breakage in unwinding but I'm not sure), but I didn't revert the patches because the bug it fixes is worse.

String hashes

The upstream hashing scheme has been reworked to have multilevel hashes and there are now two hash functions, hash_sparse and hash_dense, the former being the function luajit2 overrode with the crc32 variant. I'll propose a solution to merge the CRC32 functions with this scheme in a separate PR; in summary the solution will be to split the crc32 implementation so that the 128-byte random hashing scheme is used to override only hash_dense and not hash_sparse so that hash_sparse has minimal slowdown.

Fixes #101

siddhesh commented 4 years ago

FYI, the failing check is due to the fix for LuaJIT/LuaJIT#603 that I mentioned in the description.

siddhesh commented 4 years ago

I have created openresty/luajit2-test-suite#8 that fixes up the stackov test case to expect "error in error handling". As Mike mentioned in LuaJIT/LuaJIT#618, it is hard to avoid and hence won't be fixed. That should fix the one failing test.

agentzh commented 4 years ago

We found serious regressions on ARMv7 after merging this PR:

https://github.com/openresty/luajit2/issues/106