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

Peter Levart peter.levart at
Sun Dec 11 20:59:03 UTC 2016

Hi Alan,

On 12/11/2016 12:16 PM, Alan Bateman wrote:
> On 10/12/2016 17:11, Chris Hegarty wrote:
>> :
>> How about: Unsafe::deallocate(ByteBuffer directBuffer)?
> The alternative is of course:
> ByteBuffer wrap(long address, int capacity)
> void unmap(MappedByteBuffer)
> The wrap method allow be similar to JNI's NewDirectByteBuffer for 
> those that are managing the underlying memory themselves. This makes 
> it a more advanced method to avoid too much temptation to free the 
> memory underlying a buffer created with ByteBuffer.allocateDirect. We 
> can't do much with unmap but that at least won't be widely used.
> -Alan.

So, If I understand correctly, you are proposing users to do their own 
memory allocation/management/deallocation with Unsafe and use wrap() 
just to create a view of the allocated memory in the form of ByteBuffer. 
Wouldn't this force them to use a different approach to managing 
ByteBuffer(s) from what they do now - they would have to keep the 
allocated memory's address somewhere outside the buffer in order to free 
the memory later... It is doable, but I think Uwe will not like it very 

About unmap()... Is it just the name and signature that would discourage 
freeing memory underlying a buffer created with 
ByteBuffer.allocateDirect() or do you propose to disallow such use and 
only allow actual unmapping?

Regards, Peter

More information about the jigsaw-dev mailing list