We don't need jdk.internal.ref.Cleaner any more

[Uwe Schindler]

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