Re: Android performance drop moving from LuaJIT-2.0.1 -> LuaJIT-2.0.2 ?
- From: "Kriss@xxxxxxxx" <Kriss@xxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 11 Sep 2013 00:06:33 +0100
Thank you Mike,
Looking at trying to force some free area near lj_vm_exit_handler seems
like something that cannot be 100% guaranteed. I'd like to have a fallback
fix as well, just in case.
My current solution is to turn jit off when mcode_alloc fails to allocate
anything. The main slowdown I was experiencing was from a continuous failed
attempt to allocate memory so this does fix that.
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;
}
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.
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.
Cheers,
On Thu, Sep 5, 2013 at 11:16 PM, Mike Pall <mike-1309@xxxxxxxxxx> wrote:
> Kriss@xxxxxxxx wrote:
> > As far as I can tell the problem is just that android is not letting me
> > allocate any memory close enough to the location I want, when the range
> was
> > double it works first time.
>
> I think it's just a coincidence that it worked. It looks like
> regular memory allocations and the space for shared libraries are
> drawn from the same linear address pool. Due to the high virtual
> memory pressure in your app, all gaps around the shared library
> will eventually be filled.
>
> An easy way to work around this would be prelinking the shared
> library to a specific address far away from everything else. Alas,
> Android deprecated prelinking with 4.x due to security concerns
> and finally disabled it in 4.2.
>
> Playing with the ELF virtual load address doesn't work, because
> Bionic doesn't permit a non-zero image base address for shared
> libraries.
>
> The only workaround I can think of (without rewriting the dynamic
> linker) would be to mmap() a huge block of virtual memory with
> PROT_NONE, then load the LuaJIT shared library and munmap() the
> block right after that. That should put the shared library out of
> reach of the memory allocator.
>
> --Mike
>
>
--
Kriss
http://www.WetGenes.com/
Other related posts:
