Another take on Finalization

Bernd Eckenfels ecki at zusammenkunft.net
Fri Jun 5 23:15:16 UTC 2015


Am Fri, 5 Jun 2015 22:11:08 +0100
schrieb Jonathan Payne <core-libs at jpayne.net>:

> My problem was that finalization was not being run at all with the G1
> collector.

The problem that an object is not detected as unreachable and not
enqueued into the finalizer queue is not only a G1 problem. When an
application has very short transactions and no objects get promoted
then G1 and CMS (and PrallelOld) trigger very seldom an old GC, so this
leads to a long time that finalizeable objects do not get cleaned up.

Not sure if G1 is especially bad in that regards. I think it might
be related to the bug that it never responded to the DGC cleanup unlike
other GCs? Something similar to calling System.gc() every hour 
but with less negative effects would be a helpful tool for those
situations.

This is also a problem for other memory pools (class loaders, code
cache, constant pool, direct buffers) as well. So having a slow
background cleanup is a good thing in all cases.

> My fix, BTW, was to use a back door (that I added to SharedSecrets)
> in all the JDK classes that had a finalize() method, so that when a
> resource is properly closed, by calling the close() method for
> example, the back door would remove the Finalizer for the specified
> object from the linked list of Finalizer objects

I think it would be good to offer such an API to early remove an object
from the reference queue.

Gruss
Bernd



More information about the core-libs-dev mailing list