If your array really is "native" then #arr in your for loop should be #arr-1. Denis Golovan <denis.golovan@xxxxxxxxx> wrote: >Hi > >I'd like to share something I cannot call a relevant bug report. Unfortunately. >I could not create a small example to reproduce. But it happens rather often. > >Still I decided to give some info on the issue. Maybe it can be useful. > >Due to nature of my usage, I tend to use large native arrays I loop >over with a small amount of calculations per element. "Number >crunching", as it is usually called. > >After some time I saw a real necessity in increasing "loopunroll" >parameter. It allowed me to bring my initial speed back (difference >about 100x). It was related to deeply nested functions inside my loops >where only a really small subset of paths is used. The compiler agreed >to unroll and optimize my loops again. > >Unfortunately I began to notice some strange things after increasing >"loopunroll" parameter. >Sometimes immediately, sometimes after several minutes of >calculations, my program starts crashing in places where I access >native arrays in a loop. Those are pretty innocent looking loops like >: > >for i=0,#arr do > if arr[i] then -- native boolean array access > ... > end >end > >It looks like "arr" (which is just a wrapper for a pointer to a native >array first element) points nowhere or "i" index goes into a large >negative value. > >Currently I use a following code for setting parameters (some of them >are surely an overkill), but it helps to reduce the bug frequency >while still having a decent calculation speed. > >jit.opt.start("maxmcode=10240", "maxtrace=3000", "maxside=400", >"maxsnap=3000", "maxirconst=2000", > "hotloop=5", "hotexit=20", "instunroll=25", >"loopunroll=100", "callunroll=25") >jit.opt.start(3) >jit.opt.start("-abc") -- without this one if happens really often >jit.flush() > >I've upgraded to 2.0.3, but still no luck. > >Could you suggest something? > >P.S. I am under Linux x86 arch. > >BR, >Denis >