We don't need jdk.internal.ref.Cleaner any more
david.holmes at oracle.com
Tue Feb 16 05:24:49 UTC 2016
On 16/02/2016 6:05 AM, Mandy Chung wrote:
>> On Feb 15, 2016, at 9:06 AM, Uwe Schindler <uschindler at apache.org> wrote:
>>> On 15/02/2016 14:57, Chris Hegarty wrote:
> 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).
How did you know I would read this? :)
Thread priority has no meaning on Solaris, Linux or BSD/OSX by default.
Only Windows actually applies thread priorities under normal conditions.
The difference between MAX_PRIORITY and MAX_PRIORITY-2 is the former
uses THREAD_PRIORITY_HIGHEST and the latter
THREAD_PRIORITY_ABOVE_NORMAL. Without any real/reasonable workloads for
benchmarking it is all somewhat arbitrary. Arguably the Reference
handler thread has more work to do in general so might be better given
the higher priority.
> 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
>> 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.
More information about the core-libs-dev