RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more
peter.levart at gmail.com
Wed Feb 17 16:16:23 UTC 2016
On 02/17/2016 10:06 AM, Peter Levart wrote:
On 02/17/2016 01:20 AM, Kim Barrett wrote:
>> I don't understand why CleanerImpl needs to be changed to public in
>> order to provide access to the new drainQueue. Wouldn't it be better
>> to add Cleaner.drainQueue?
> An interesting idea. But I don't know if such functionality is
> generally useful enough to commit to it in a public API.
> I have another idea where java.lang.ref.Cleaner would use an Executor
> instead of ThreadFactory. The default would be an instance of a
> single-threaded executor per Cleaner instance, but if user passed in a
> ForkJoinPool, he could use it's method ForkJoinPool.awaitQuiescence()
> to help the executor's thread(s) do the cleaning.
...well, this would not be a good idea as ReferenceHandler thread would
then have to feed the Executor (invoke Executor::execute(Runnable)) and
a user-specified Executor could abuse that. There has to be a queue API
between ReferenceHandler and custom user code.
More information about the core-libs-dev