I would argue that we should favor ints wherever possible. At the end we do Java array accesses and they only take ints. Even if there is no performance regression a horrible cascade of (int) casts will appear in the code for the long case, making it much harder to read.

I also assume that there IS performance loss if every access did a[(int)x] instead of a[x]

ML: Andreas - you were working on fixing this, but we decided, I think to go with mostly ints and treat negative and too large once as special cases of SparseArrayFilter

AW: I can do a performance assessment later. I agree we should favor long indices, if there is no regression. Otherwise I think it's ok to use ints.

ML: I would argue that we should favor ints wherever possible. At the end we do Java array accesses and they only take ints. Even if there is no performance regression a horrible cascade of (int) casts will appear in the code for the long case, making it much harder to read.

I also assume that there IS performance loss if every access did a[(int)x] instead of a[x]

AW: Yes, there probably is some performance loss (in fact, from my measurements, I think there's a minimal loss already from using longs now where we had used int before). Attached webrev.zip that add long get and set methods to ArrayData. Also ironed out a few glitches here and there. Passes ant test and test262parallel. Unfortunately, I'm getting lower scores on crypto and navier-stokes... :-\