The new numbers are appearing here:
Dave was completely right. jess shows naive use of memmove to be a bad choice.
The "memmove 512" column is the same broken setup as shown earlier. What happens there is we a) treat all copies as non-overlapping but only call to memmove when the copy is less than 512. While memmove is safe for overlapping arrays, the other java code is not (it is not intended to be). So it is surprising that only jython crashes.
Sorry for wasting your time with these bogus numbers! Fortunately we can still derive something interesting from the data:
a) primitive array copy performance can significantly affect the bottom line in real benchmarks.
b) by looking at the "naive" numbers, we can now see which benchmarks are sensitive to array copy performance.
c) javac appears to do a lot of overlapping copies, so we win considerably by bypassing that logic (though of course to do so is incorrect)