RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Jason Mehrens]

Hi Roger,



Thinking more on it, the 'thunk' objects could pin a class loader too so pinning the CCL should be obvious.



I'm just having flashbacks of https://bugs.openjdk.java.net/browse/JDK-8025251 and trying to find any pitfalls in this code.  The InnocuousThread is interesting because the workaround of setting the CCL in the 'thunk' would never work.  It would work with the Executors.defaultThreadFactory() so that seems like something to warn lib designers about.  I don't know of a good example where such a warning in the JDK.  The Runtime.addShutdownHook would be the only place but since the user is creating a thread an not just a runnable it doesn't apply there.



Jason



________________________________
From: Roger Riggs <Roger.Riggs at Oracle.com>
Sent: Friday, October 2, 2015 10:06 AM
To: Jason Mehrens; Core-Libs-Dev
Subject: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Jason,

The caller that creates the Cleaner does contribute some of its state to the new Thread
including the normal inheritance of the ContextClassLoader, InheritableThreadLocals, etc.

So yes, if in your context the ThreadFactory would take precautions then the thread factory used
for the Cleaner would be no different.

The default factory uses sun.misc.InnocuousThread which explicitly sets
the context classloader to the System class Loader and discards inheritable thread locals.

Is there an example of the warning you suggest elsewhere in the JDK?

Thanks, Roger



On 10/2/2015 10:14 AM, Jason Mehrens wrote:

Roger,

For custom thread factories, do we have to explictly set the CCL for the created thread or should that be a documented as a warning to all who use it?  In web apps that can be a form of a memory leak.

Jason

_______________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net><mailto:core-libs-dev-bounces at openjdk.java.net> on behalf of Roger Riggs <Roger.Riggs at Oracle.com><mailto:Roger.Riggs at Oracle.com>
Sent: Thursday, October 1, 2015 9:12 AM
To: Core-Libs-Dev
Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative    to finalization

Please review a proposal for public Cleaner API:

A Cleaner is proposed to provide an easy to use alternative to
finalization. The service would provide easy registration and
cancellation of cleanup functions for objects. Applications create a
cleanup service for their own use and the service terminates when it is
no longer in use.

Finalization has a long history of issues both in usage and performance.
PhantomReferences have been proposed as the alternative GC based
mechanism for cleaning functions but it has been left as an exercise to
the developer to construct the necessary mechanisms to handle
ReferenceQueues, handle threading issues and robust termination.

The Cleaner performs cleaning functions when objects are unreachable as
found by garbage collection using the existing mechanisms of
PhantomReference, WeakReference, SoftReferences, and ReferenceQueues. It
manages a thread that dequeues references to unreachable objects and
invokes the corresponding cleaning function. Registered cleaning
functions can be cleared if no longer needed, can be invoked explicitly
to perform the cleanup immediately, or be invoked when the object is not
reachable (as detected by garbage collection) and handled by a cleanup
thread.

The java.lang.ref package is proposed for the Cleaner because it is
complementary to the reference classes and reference queues and to make
it easy to find.

It is not a goal to replace all uses of finalization or sun.misc.Cleaner
in the JDK.
Investigation will evaluate if and in what cases the Cleaner can replace
finalization.
A subsequent task will examine uses of finalization and propose specific
changes
on a case by base basis.

Please review and comment:

Javadoc:
   http://cr.openjdk.java.net/~rriggs/cleaner-doc/

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Issue:
    https://bugs.openjdk.java.net/browse/JDK-8138696

Thanks, Roger