Re: Android performance drop moving from LuaJIT-2.0.1 -> LuaJIT-2.0.2 ?
- From: Mike Pall <mike-1309@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 11 Sep 2013 23:25:05 +0200
Kriss@xxxxxxxx wrote:
> The end of mcode_alloc now looks like this. Is this safe to do here?
>
> J->flags &= ~(uint32_t)JIT_F_ON;
> lj_dispatch_update(J2G(J));
> lj_trace_err(J, LJ_TRERR_MCODEAL); /* Give up. OS probably ignores
> hints? */
> return NULL;
> }
Yes, but the lj_dispatch_update() should be removed. The
trace abort already runs that.
> Obviously turning off jit is not ideal and I would rather return a block
> that may be anywhere and patch asm_exitstub_gen to test how close the block
> is to lj_vm_exit_handler and then emit a "longjump" rather than a BL.
Well, that solves only part of the problem.
> Is that a sane idea? Any other problems this might generate? My main worry
> is simply not understanding everything going on here and trying to do
> something silly.
All generated machine code needs to be able to branch to every
other piece of generated machine code. So all of the segments have
to stay within the branch range.
You could try to force a single big machine code segment:
-Osizemcode=524288,maxmcode=524288
Or from Lua code (before you do anything else):
require("jit.opt").start("sizemcode=524288,maxmcode=524288")
for i=1,100 do end -- Force allocation of the first segment.
If it's able to grab the 512K at the beginning then it shouldn't
get into that problem. It's probably ok with even less memory.
--Mike
Other related posts:
