fsfod/luajit

Mirror of the LuaJIT git repository

luajit's Issues

Get new GC in LuaJIT upstream

It would be very useful to get the new GC upstreamed.

gcarena: compile errors on linux

in lj_gc.c:963 the function sweep_arena is forward declared as void sweep_arena(global_State *g, MSize i); but is later declared as static void sweep_arena(global_State *g, MSize i, MSize celltop)

I changed the forward declaration to the latter and passing 0 as the argument for MSize celltop in lj_gc.c:975

Now I get a bunch of errors in enablelargepages at lj_alloc.c:412 where windows specific functions are being used.

Just commenting that out the contents of the function and returning 0 I get a linker error:

/usr/bin/ld: lj_vm_dyn.o: relocation R_X86_64_PC32 against symbol `lj_gc_emptygrayssb' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

There are also many warnings
https://gist.github.com/CapsAdmin/c5cab3e28f9cad5af1d15811e3c097f2

Read-only tables performance

I am very interested in the read-only tables feature. I have seen promising results in a microbenchmark (LuaJIT#248 (comment)) and now I am testing with a real application (Snabb).

Initial scores are low on my simplest Snabb benchmark. Baseline score is 27, merging the readonlytables branch (commit 68515a2) this drops to 7, and adding a couple of calls to table.setreadonly() that I expected to be beneficial dropped the score to 0.1. So the opening position is a 270x slowdown and I am keen to improve on this :-)

Just quick questions if I may:

• Is readonlytables the right branch? I also see readonly_tables.
• Any loose ends in the implementation that I should be aware of?
• Any immediate idea on what could cause a performance drop even when not calling table.setreadonly()?

Cheers!

vectors: segmentation fault __memcpy_sse2_unaligned ()

compiled with gcc 5.4.0 on x64 linux with the flags LUA_USE_ASSERT, CCDEBUG=-g and CCOPT=-fomit-frame-pointer

I applied this patch on the vectors branch to get it compiling
https://gist.github.com/CapsAdmin/00326ad8eda9ca48557013bcd90546fc

Only happens when jit is on.

Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:38
38      ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:38
#1  0x000000000043f1dd in lj_cf_ffi_copy (L=0x40000378) at lib_ffi.c:721
#2  0x000000000044249e in lj_BC_FUNCC ()
#3  0x000000000041ac9e in lua_pcall (L=0x40000378, nargs=0, nresults=-1, errfunc=2) at lj_api.c:1055
#4  0x000000000040440e in docall (L=0x40000378, narg=0, clear=0) at luajit.c:121
#5  0x0000000000404dee in handle_script (L=0x40000378, argv=0x7fffffffde28, n=1) at luajit.c:288
#6  0x0000000000405b23 in pmain (L=0x40000378) at luajit.c:537
#7  0x000000000044249e in lj_BC_FUNCC ()
#8  0x000000000041af48 in lua_cpcall (L=0x40000378, func=0x405965 <pmain>, ud=0x0) at lj_api.c:1079
#9  0x0000000000405c29 in main (argc=2, argv=0x7fffffffde28) at luajit.c:565
(gdb) 

I'm able to pinpoint where it crashes in some situations but it seems random and attempting to debug the code will move the crash somewhere else. When it's not crashing there is weird behavior such as random nonsense lua errors.

Merge intrinsic implementation branches with upstream

I'm still interested in this but they are kind of behind 2.1 at the moment. GC64 also seems to work really well now.

intrinsicpr: crash when running tests with gc64

(gdb) run runtests.lua 
Starting program: /home/caps/goluwa/framework/lua/build/luajit_forks/repo/fsfod-intrinsicpr_debug-assert_52compat_gc64/src/luajit runtests.lua
running fpr
running gpr
running gpr64

Program received signal SIGSEGV, Segmentation fault.
0x000000001815fe74 in ?? ()
(gdb) bt
#0  0x000000001815fe74 in ?? ()
#1  0x00000000004594e4 in lj_intrinsic_call (cts=0x7fbb7afe4c48, ct=0x7fbb7afdfa08) at lj_intrinsic.c:916
#2  0x00000000004b49e6 in lj_ccall_func (L=0x7fbb7b003378, cd=0x7fbb7afc0fb0) at lj_ccall.c:1156
#3  0x000000000043cc4a in lj_cf_ffi_meta___call (L=0x7fbb7b003378) at lib_ffi.c:232
#4  0x0000000000444de2 in lj_BC_FUNCC ()
#5  0x000000000041c28c in lua_pcall (L=0x7fbb7b003378, nargs=0, nresults=-1, errfunc=2) at lj_api.c:1129
#6  0x00000000004046ae in docall (L=0x7fbb7b003378, narg=0, clear=0) at luajit.c:121
#7  0x000000000040504d in handle_script (L=0x7fbb7b003378, argx=0x7fffffffd840) at luajit.c:291
#8  0x0000000000405d61 in pmain (L=0x7fbb7b003378) at luajit.c:551
#9  0x0000000000444de2 in lj_BC_FUNCC ()
#10 0x000000000041c57a in lua_cpcall (L=0x7fbb7b003378, func=0x405b81 <pmain>, ud=0x0) at lj_api.c:1153
#11 0x0000000000405e71 in main (argc=2, argv=0x7fffffffd838) at luajit.c:580

State of development on newgc_split

I just noticed you've been working on a new garbage collector for LuaJIT. I tried building the repo on windows but got a few errors regarding some missing defines (LJ_GC_ARENA_SIZE and LJ_GC_FIXED).

We are heavy users of LuaJIT in our games but are noticing garbage collection spikes more and more often as our games grow larger. I was wondering whether this new garbage collector would reduce this issue (I find it very hard to debug these spikes).

Could you maybe talk a little bit about your plans and state of development of your implementation?