Proposal for finalizer optimization.

[Ramón García]

Thanks for the points. I think that they can be solved, for instance,
by running the finalizer after the GC, but then deleting the object
immediately instead of enqueing it again. Other option would be to
call the finalizer, but don't wait for it, just leave it running and
ensure that the memory is released afterwards.

With regard to native method calls, finalizers can (and usually do, I
think) call native static functions that do not receive the this
argument, only the fields necessary for releasing native resources
(such as the native file handle).

On Nov 26, 2007 9:46 AM, Tony Printezis <tony.printezis at sun.com> wrote:
> Ramon,
>
> You really can't just call the finalizer from the GC. Usually, the GC
> works when the application threads are stopped (i.e., during a
> "stop-the-world" pause) and no Java code is running (and the finalizer
> is Java code). There might be some synchronization issues as well.
> Imagine that the finalizer wants to take a lock that another thread is
> holding; this would deadlock the GC, as the other thread is not running
> and is waiting for the GC to complete. Finally, finalizers are arbitrary
> Java methods that can take an arbitrarily long time to execute; if you
> run them as part of the GC, you'll introduce a lot of unpredictability
> on duration of the GC. Another bummer is that most finalizers call a
> native method to do some native resource reclamation. As a result, you
> can't do some static analysis over them (i.e., you'd have to analyze
> machine code, not Java bytecodes).
>
> Tony
>
>
> Ramón García wrote:
> > Yes, the idea is to run object.finalize() exactly before reclaiming
> > object's memory.
> >
> > Ramon
> >
>