Hi Chris, thanks, works perfectly. I compiled a JDK with this commit and Lucene's unmapping works. Thanks. https://github.com/apache/lucene-solr/compare/LUCENE-6989-v2
Uwe ----- Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Friday, December 16, 2016 6:39 PM > To: Peter Levart <peter.lev...@gmail.com>; Core-Libs-Dev <core-libs- > d...@openjdk.java.net>; jigsaw-dev <jigsaw-...@openjdk.java.net>; Uwe > Schindler <uschind...@apache.org> > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Pushed to jdk9/dev. Should make b150. > > https://bugs.openjdk.java.net/browse/JDK-8171377 > > -Chris. > > > On 14 Dec 2016, at 11:58, Chris Hegarty <chris.hega...@oracle.com> > wrote: > > > > Webrev updated in-place. > > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > > > -Chris. > > > > On 13/12/16 21:18, Peter Levart wrote: > >> I think this is OK. > >> > >> Just a couple of nits in test: > >> > >> 1. You create a static Path bob = Paths.get("bob") field, but then you > >> don't use it in: > >> > >> 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), > >> CREATE, WRITE)) { > >> > >> 2. badBuffers could include a duplicate and a slice of a direct buffer > >> allocated with ByteBuffer.allocateDirect() > >> > >> 3. The comment in the test is referencing the old method name: > >> > >> 26 * @summary Basic test for Unsafe::deallocate > >> > >> > >> Regards, Peter > >> > >> On 12/13/2016 08:47 PM, Chris Hegarty wrote: > >>> Taking into account the feedback so far, and changing the method name > ( since > >>> it is an attractive nuisance ), here is where I think we ended up. > >>> > >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > >>> > >>> If this is agreeable, I’ll file an issue in JIRA to track the code > >>> changes, and > >>> update JEP 260. > >>> > >>> -Chris. > >>
