Hi Mark,
Memory is an increasingly critical resource, we should be giving
developers more tools
to manage their use of memory. The Weak and Soft reference forms of the
cleaner make
it easier to be aware of and respond to increased memory pressure.
The management of memory is not hypothetical for most large
applications. It was one topic
that came up in questions at J1. Developers do quite a bit of work
trying to figure out algorithms
for working caches, serializing to disk, and having the data available
when it is needed.
There is a lot of guesswork about how GC is working and how it behaves
at/near the limits.
SoftReferences are a bit of a blunt instrument but they provide evidence
an application
can use to regulate its long term memory use.
The WeakReference forms, if provided, can be an alternative to the
ideosyncratic
cleanup approaches used in various Weak keyed and weak values collections.
sssssssssssssssssssssssssssssssssssssssss
If there are other mechanisms contemplated for more efficient memory
management
then perhaps these are not necessary but if not the current mechanisms
should be easier to use.
Roger
On 11/23/2015 5:32 PM, mark.reinh...@oracle.com wrote:
( Finally getting back to this, after too many weeks of travel ... )
2015/10/20 11:28 -0700, roger.ri...@oracle.com:
Sorry for the silence, JavaOne preparations and the availability of
folks who wanted to review have stretched things out.
The Cleaner API was very simple and saw feature creep as the ideas for
how it might be used were explored. There are concerns about
committing to supporting subclassable CleanableReferences in all
future JDK versions before there had been a chance to see how if they
would be useful and necessary to address the need to reduce the use of
finalization within the OpenJDK and beyond.
...
Updated Javadoc:
http://cr.openjdk.java.net/~rriggs/cleaner-doc/
Updated Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
I'm very happy to see this API return to something like its original
simple form, but I think it can be simplified even further.
We have a very strong need for phantom-ref-based cleaners, so as to
discourage people from relying upon flaky finalization. The arguments in
support of the weak and soft forms have, by contrast, been rather weak
(and soft?). I don't think it's right to bake methods into a core API
based on just a couple of hypothetical use cases. I'd much rather see
the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single
register method,
Cleaner.Cleanable register(Object, Runnable);
which would create the phantom form only. If strong justification for
the other forms arise then we can generalize this later, either to
distinct register{Soft,Weak} methods or, perhaps, to a method that takes
a type token.
- Mark
