Some debugging logs attached so you can hopefully see what is going wrong for me. It repeats itself so this is just a small snippet of the output. Also included is the logging changes to the code so you can be sure what the numbers in the logs mean. 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. The only reason I can think of why it might be biting me and not anyone else is either related to the size of my code section or possibly that I have broken the linker somehow and ended up at a strange base address. Is there anything else you would like to know? Cheers, On Thu, Sep 5, 2013 at 4:19 AM, Kriss@xxxxxxxx <Kriss@xxxxxxxx> wrote: > After some more prodding it seems that It really is that memory allocation > loop failing to allocate anything. > > When the range is bigger, it succeeds, with that -1 it actually falls > through after trying 32 times. > > With the bigger range it loops a few times at the start, then it is OK > from then on in as it hits a good free chunk on its first guess. > > Sorry failed to get a map, I think I need to root this device before I can > see proc/?/maps. I'll get on that tomorrow. Sorry, not dealt with the > android internal stuff too much I mostly rely on testing locally and hoping > it will just work :). > > I suspect that part of the problem here may be that I have 5meg of native > code+data in a single .so and the function you are trying to allocate > memory near is in the middle. So it really is having trouble finding free > memory within the range and whatever restrictions android is applying. > Maybe I can convince the linker to do something clever to fix this. > > > Cheers, > > > On Thu, Sep 5, 2013 at 1:28 AM, Mike Pall <mike-1309@xxxxxxxxxx> wrote: > >> Kriss@xxxxxxxx wrote: >> > By a process of just reverting files between the two versions I have >> > pinpointed exactly what is going wrong. Not really sure why it is bad >> for >> > me and not anyone else? >> > >> > The change is in lj_mcode.c, >> > >> > const uintptr_t range = (1u << (LJ_TARGET_JUMPRANGE-1)) - (1u << 21); >> >> [Well, I'm relieved it's not an isue with cache syncing. But ...] >> >> Please print or log the address of lj_vm_exit_handler (e.g. in >> lua_newstate), then take a look at the memory map /proc/self/maps >> or /proc/$pid/maps after running for a while. There should be >> enough free memory around this address in the +-32 MB ARM branch >> range. >> >> The JIT-compiler tries to grab 32 KB blocks from that area and >> will do random probes until if finds one. That could be costly if >> this fails too often. You can check whether this is the problem by >> adding some logging to the end of mcode_alloc() where it punts. >> >> [There was another thread about a Tegra-based device in April. >> When I debugged that I noticed the whole memory map was full of >> tiny 4K mappings against /dev/nvmap. I'm not sure whether that's >> normal or not. From a quick search, I'm under the impression that >> device should be opened once per process and not hundreds of >> times. Maybe something is leaking graphic driver handles or such?] >> >> --Mike >> >> > > > -- > Kriss > > http://www.WetGenes.com/ > -- Kriss http://www.WetGenes.com/
Attachment:
luajitprob.zip
Description: Zip archive
