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

[Andrew Haley]

On 11/12/16 18:33, Peter Levart wrote:
> In order for deallocation to be effective and, above all, safe, user has 
> to know the whole story of a buffer (s)he intends to deallocate and the 
> story of all possible derived buffers. I don't believe one can create a 
> safe program by choosing to deallocate a direct buffer for which (s)he 
> does not know where it came from, because then (s)he also doesn't know 
> what other buffers might still be using the same piece of memory.

This is JDK-4724038.  It is possible to unmap a MappedByteBuffer
safely with little effect on efficiency: my basic idea is to add an
indirection which all callers (even those using derived buffers) have
to use to access the memory, and then removing most uses of this
indirection with a little compiler magic.  A few will still remain, but
these will be the minimum required to guarantee security and won't
affect the speed of most operations.

I have a plan to implement this, but it requires changes to the Java
Memory Model and to the compilers.  I didn't get it done in time for
JDK 9 because of being distracted by a ton of other things, but I hope
I'll get it done by JDK 10.

Andrew.