Re: SIGSEGV in LuaJIT 2.1 VM

  • From: Igor Ehrlich <igor.a.ehrlich@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sat, 26 Nov 2016 09:00:43 +0300

Obviously the JVM should have the same problem
No it should not.

The main problem with LuaJIT here is that it changes memory protection of
the same page of memory due to trace additions/patches. I believe this
could've been avoided even in LuaJIT by mcode management re-design (putting
different traces in different pages and creating per-trace exit trampolines
in RW memory. The latter wouldn't even slow down code for x86_64). And the
issue was surely avoided by JVM developers.

Also, it does not make a difference if the application is single-threaded
or multi-threaded, like at all. The amount of different cores at the OS
disposal is what matters.

On Sat, Nov 26, 2016 at 8:44 AM, Demi Obenour <demiobenour@xxxxxxxxx> wrote:

What does the JVM do in the same situation?  Obviously the JVM should have
the same problem, and it routinely runs in environments where crashes would
be disastrous.  And it is multi-threaded.

What about issuing a cache flush instruction? (clflush I think).

On Nov 25, 2016 6:26 AM, "Tomas Kvasnicka" <nzt4567@xxxxxxx> wrote:

I hate to be that guy but… it crashed. After silently waiting for sharing
the victory moment with you at the end of the week LuaJIT + Intel stabbed
me without mercy. It crashed only once a week though (several hours ago)
instead of once a day so there is some progress :) Peter, if there is
anything else on your mind we could try I’ll be more then happy to co-op.
Otherwise, thread affinity I guess - our nginx processes are running with
only one thread per process -> would it be correct to assume that setting
the affinity for the whole process using a tool like e.g. tasklet might do
the trick quickly and easily (at least to test the performance impact)?

Thank you all for your ideas and help!




Other related posts: