On 23/01/16 20:01, Uwe Schindler wrote: > It depends how small! If the speed is still somewhere between Java 8 > ByteBuffer performance and the recent Hotspot improvements in Java > 9, I agree with trying it out. But some volatile memory access on > every access is a no-go. The code around ByteBufferIndexInput in > Lucene is the most performance-critical critical code, because on > every search query or sorting there is all the work happening in > there (millions of iterations with positional ByteBuffer.get* > calls). As ByteBuffers are limited to 2 GiB, we also need lots of > hairy code to work around that limitation!
Yes, I see that code. It would be helpful if there were a self-contained but realistic benchmark using that code. That way, some simple experiments would allow changes to be measured. > If you look at ByteBufferIndexInput's code you will see that we > simply do stuff like trying to read from one bytebuffer and only if > we catch an BufferUnderflowException we fall back to handling buffer > switches: Instead of checking bounds on every access, we have > fallback code only happening on exceptions. E.g. if you are 3 bytes > before end of one buffer slice and read a long, it will throw > BufferUnderflow. When this happens the code will fall back to read > byte by byte from 2 different buffers and reassemble the long): I'm surprised you don't see painful deoptimization traps when that happens. I suppose it's rare enough that you don't care. There's a new group of methods in JDK9 called Objects.checkIndex() which are intended to provide a very efficient way to do bounds checks. It might be interesting to see if they work well with ByteBufferIndexInput: that's an important use case. BTW, does anyone here know why we don't have humongous ByteBuffers with a long index? Andrew.
