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
