Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Peter Levart]

On 12/10/2016 09:00 PM, Uwe Schindler wrote:
> Hi,
>
> We noticed that buffers with zero length also have no cleaner. This is 
> why we also have the null check in our code (see Github) and the 
> guardWithTest in the MethodHandle, although we never free duplicates. 
> So a noop is better imho.

Oh yes, good catch. Then what about being noop just for zero length? I 
don't know, maybe I'm just being paranoid and those who would use this 
API know perfectly well what they are doing. I'm just imagining a 
situation where one would create and keep just a duplicate of a direct 
buffer and afterwards use it to try to deallocate the native memory. 
This would be a noop, but the developer would think it works as GC would 
finally do it for him. I think it's better to throw an exception to 
prevent such situations...

Regards, Peter

>
> I like the Unsafe approach. To me both variants are fine.
>
> Uwe
>
> Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart 
> <peter.levart at gmail.com>:
>
>     Hi Chris,
>
>
>     On 12/10/2016 06:11 PM, Chris Hegarty wrote:
>>     How about: Unsafe::deallocate(ByteBuffer directBuffer)?
>>        http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
>
>     Apart from the fact that Unsafe is (was?) reserved for low-level
>     stuff, I think this approach is reasonable. Is the method in
>     jdk.internal.misc.Unsafe needed? You could add the method just to
>     the sun.misc.Unsafe (to keep internal Unsafe free from hacks) and
>     export the two packages selectively to jdk.unsupported.
>
>>     We could attempt to limit this to the direct buffer that "owns" the
>>     memory, i.e. not a duplicate or a slice, but I'm not sure it is worth
>>     it.
>
>     What you have here *is* limited to direct ByteBuffer(s) that "own"
>     the memory. Derived buffer(s) (duplicated or sliced) do not have a
>     Cleaner instance (they have an 'attachment' to keep the 1st-level
>     buffer reachable while they are reachable). I would even make it
>     more unforgiving by throwing an IAE if the passed-in buffer didn't
>     have a Cleaner. In addition I would specify this behavior. For
>     example:
>
>     "Deallocates the underlying memory associated with given
>     directBuffer if the buffer was obtained from either {@link
>     ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In
>     any other case (when the buffer is not a direct buffer or was
>     obtained by  {@link ByteBuffer#duplicate() duplicating} or {@link
>     ByteBuffer#slice(int, int) slicing} a direct buffer), the method
>     throws {@code IllegalArgumentException}.
>
>     Regards, Peter
>