JEP 132: More-prompt finalization

[Mandy Chung]

> On Jun 27, 2015, at 2:31 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
>>> Are any of the features of this prototype interesting for you and worth pursuing further?
>> This mostly appears to be a question for core-libs; that's where the
>> proposed changes are located.  GC is involved mostly to ensure the
>> internal APIs between the collector and reference processing are
>> maintained.
>> 
>> My personal opinion is that we should be working toward a day when we
>> can remove the finalize function, rather than trying to make the
>> infrastructure around it faster.  But clearly that day won't be soon,
>> if ever.
>> 


I agree.  We should put efforts in removing our JDK use of finalizer, as many as we can, and that will help tune the design of any new Cleaner-like API.   

> 
> The infrastructure is shared for all Reference kinds. Improving it impacts all reference processing, not only finalization. If it makes finalization faster too, it can be viewed as just a coincidence ;-)
> 

Improving the reference processing is definitely attractive work.   This work is not a small task and also due to its complexity, we will have to look at this closely after several months once we complete some feature works targeted for JDK 9.  We probably should write a JEP for this when that time comes.  


> But I agree. We should move internal code away from finalization and also give users viable alternatives that would make finalize() method obsolete one day.



+1. 

Mandy