> On Feb 15, 2016, at 9:06 AM, Uwe Schindler <uschind...@apache.org> wrote: > > Hi, > >> On 15/02/2016 14:57, Chris Hegarty wrote: >>> Peter, >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/ >>>
This patch looks correct to me. The innocuous thread created for common cleaner is of Thread.MAX_PRIORITY - 2 priority whereas the reference handler thread is of MAX_PRIORITY priority. I don’t know if this would impact any real-world application or whether worth having a dedicated thread with MAX_PRIORTY (David Holmes may have recommendation to this). Another subtle difference is no more package access check whether running with security manager. On the other hand, “suppressAccessChecks” permission is still checked. I don’t have issue with this. >>> 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? I believe Alan refers to the fast path handling jdk.internal.ref.Cleaner via the Reference Handler thread. What this means to existing code is that the java.nio.DirectByteBuffer::cleaner method still exists but with java.lang.ref.Cleaner.Cleanable return type. You still need to call setAccessible(true) on the cleaner method. You can then statically reference java.lang.ref.Cleaner.Cleanable::clean method Mandy > 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 >
