JDK-8144531 : Cleanup of Cleaner implementation
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-12-02
  • Updated: 2021-12-03
  • Resolved: 2021-12-03
Related Reports
Duplicate :  
JDK-8251861 - Remove unused jdk.internal.ref.SoftCleanable and WeakCleanable
Relates :  
JDK-8138696 - java.lang.ref.Cleaner - an alternative to finalization
Description
The implementation of java.lang.ref.Cleaner in jdk.internal.misc.CleanerImpl includes support for cleaning of weak and soft references.  If they remain unused after the conversion of classes from finalization to Cleaner and other uses, the dead code should be removed.
Comments
Deferring from 9 to look at early in 10 at Peter's proposed design/implementation changes at the same time as putting them to use allowing fine tuning of the API.
27-01-2017
http://download.java.net/java/jdk9/docs/api/java/lang/ref/Cleaner.html Two compile errors here: private final State; private final Cleaner.Cleanable cleanable I keep being confused by the naming in the example code. "State" is the thing that actually does the cleaning, so I want to call it "Cleaner" but that's already taken. Maybe Cleaner should be renamed to "CleaningService" or even something like "CleaningExecutor". I keep thinking that having a 1-1 mapping between Cleaners and Threads will turn out to be a design mistake. Back in 2005 we told people to replace all their uses of Threads with Executors. Old JDK has ability to create secondary finalizer threads, useful when the dedicated finalizer thread can't keep up with all the work in big servers. CleanerFactory.cleaner() actually returns a constant. Easier to understand might be systemCleaner(). It keeps bothering me that we need to allocate two objects (Runnable and Cleanable) per registered object, which was not true of the old finalizer scheme. But I don't have a good solution.
19-05-2016
Include the cleanup and comments provided in: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040923.html
09-05-2016