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

[Peter Levart]

Hi,

I had an idea recently on how to expedite the collection of an object. 
It is simple - just don't let it live long.

Here's a concept prototype:

http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java

The overhead of the check in access methods (getByte()/setByte()) 
amounts to one volatile read of an oop variable that changes once per 
say 5 to 10 seconds. That's the period a special guard object is alive. 
It's reachability is tracked by the GC and extends to the end of each 
access method (using Reference.reachabilityFence). Every few seconds, 
the guard object is changed with new fresh one so that the chance of the 
guard and its tracking Cleaner being promoted to old generation is very low.

Could something like that enable a low-overhead CloseableMappedByteBuffer?

Regards, Peter

On 01/23/2016 09:31 PM, Andrew Haley wrote:
> 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.