RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Andrew Haley]

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.