Hi, > On 15/02/2016 14:57, Chris Hegarty wrote: > > Peter, > > > > > > > http://cr.openjdk.java.net/~plevart/jdk9- > dev/removeInternalCleaner/webrev.02/ > > > > Given the changes in 6857566, I think your proposal to remove > > jdk.internal.ref.Cleaner should be good. ( Note: third party libraries > > digging into internals of direct buffers will need to change again ). > > > I think so too, the main think is that the fast path for cleaners has > been removed (and I see that it has).
What do you mean with fast path? The usual code pattern for forceful unmapping did not change: - Make java.nio.DirectByteBuffer#cleaner() accessible (this is the thing where you need to fight against the Java access checks). - call clean() (Runnable#run() in previous commit) on the returned object (with correct casting to interface before calling, this is where existing legacy code must change). In preparation for these changes, I made a patch for Lucene (Solr/Elasticsearch) to "compile" the whole unmapping logic into a MethodHandle (this allows me to do all needed accesibility/security checks early on startup and before actually invoking unmapping). This allows us to tell user that forceful unmapping works *before* we actually need to call it: https://issues.apache.org/jira/secure/attachment/12787878/LUCENE-6989.patch This will be part of Lucene 6.0 which will require Java 8 as minimum. Earlier Lucene version will not be compatible to Java 9 and can only be used in "slower" non-mmap mode. Thanks, Uwe
