Bug: ICC_Profile has un-needed, not-empty finalize method
Webrev: http://cr.openjdk.java.net/~prr/8175984/
This is a native memory utilisation problem due to delay in collecting and
freeing ICC_Profiles and their associated classes and data.
The color management engine is native code and consumes the stream of data
representing the ICC profile and constructs internal native data structures.
The delay is because the garbage collector doesn't know about the native
memory
consumption and from a Java perspective there is no need to initiate
garbage collection.
But it is worse than that because even collection when does happen it is
delayed in
freeing this memory.
The native data is referenced internally via a Profile object which is
registered with the 2D disposer
so that the data will be freed after the disposer's reference to it is
enqueued and cleared.
The disposer needing to run does add some delay but there's a further delay.
ICC_Profile has non-empty finalize which is there to free this native data.
This used to matter with the old closed source CMS *only* because no one
bothered
to implement 2D disposer support for it.
But the call in finalize() is a no-op for LCMS
So currently the ICC_Profile has to be finalized and only then can the
GC initiate
clearing the weak refs and freeing the native data.
Emptying the finalize() [*] method helps make the reclamation more prompt.
It is still possible to see large amounts of native memory consumed but
it is
much better than before.
[*] For those who don't know, the VM treats an empty finalize() method
as non-existent
so the object does not need to be finalized.
I had started to look at adding Disposer code to do the other thing that
the finalize() method does which is remove a deferred activation
registration
but decided this was pointless.
That is used only for the pre-defined instances held in static variables
of the class
and those live for the life of the VM so will never be freed ...
There is more clean up that could be done in the lower classes - is
freeProfile needed any more ?
Do we actually want to keep the deferral mechanism ?
Can we do something to provide a way to more promptly free the data,
perhaps via new API ?
But I decided to keep it to a minimum for safe and trivial backporting
and leave the rest
to another day.
-phil.
