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

[Peter Levart]

On 02/08/2016 07:27 AM, Alan Bateman wrote:
>
> On 07/02/2016 22:20, Peter Levart wrote:
>> :
>>
>> If the decision to remove sun.misc.Cleaner was partly influenced by 
>> the desire to maintain just 2 instead of 3 Cleaner(s), then my 
>> proposal to migrate JDK code to the public API might enable Oracle to 
>> reconsider keeping sun.misc.Cleaner.
>
> The main issue driving this is the design principles that we have 
> listed in JEP 200. We don't want a standard module (java.base in this 
> case) exporting a non-standard API. This means surgery to jettison the 
> sun.misc package from java.base and move it to its own module 
> (jdk.unsupported is the proposal in JEP 260). This is painful of 
> course but we are at least in good shape for the most critical 
> internal API, sun.misc.Unsafe.
>
> For sun.misc.Cleaner then the original proposal was for it to be a 
> critical internal API too but it become clear that changing the type 
> of internal/private fields in the NIO buffer and channel classes would 
> break libraries that have been hacking into those fields. If they are 
> changing away then there seems little motive to keep sun.misc.Cleaner 
> so Chris moved into into jdk.internal.ref for now. As to whether we 
> even need to keep jdk.internal.ref.Cleaner then I think the only 
> remaining question was whether the special handling of Cleaner in the 
> Reference implementation was worth it or not. It may not be, in which 
> case your current proposal to just remove seems right.
>
> -Alan.

The special-casing of sun.misc.Cleaner in ReferenceHandler thread is 
there to avoid bringing another thread into the processing pipeline, 
right? Presumably to optimize the latency of clean-up operations. But it 
seems that introducing another thread to the pipeline is not the source 
of problematic latency when cleaning-up direct/mapped byte buffers. The 
source of latency is the strategy of generational GC which promptly 
discovers and enqueues young References with young referents, but is not 
so prompt with old References having old referents.

If special-casing in ReferenceHandler is removed then an opportunity 
opens to get rid of ReferenceHandler thread altogether. VM/GC could 
enqueue Reference(s) to their respective ReferenceQueue(s) directly, so 
everyone could enjoy the benefits sun.misc.Cleaner has...

Regards, Peter