[OpenJDK 2D-Dev] RFR: 8175984 : ICC_Profile has un-needed, not-empty finalize method
philip.race at oracle.com
Fri Oct 11 22:43:50 UTC 2019
On 10/11/19, 2:52 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> It looks like after the fix we will skip the call "unregisterDeferral"
> the ProfileActivator which was registered by the
> "ProfileDeferralMgr.registerDeferral" will not be removed --> memory
I discussed that below in my initial email. It won't in practice leak
> 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
>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 ...
> BTW do we have an option to mark this "finalize" as forRemoval=true or
> just delete it?(example JDK-8159009/JDK-8212198)
> On 10/11/19 2:01 pm, Philip Race wrote:
>> 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
>> representing the ICC profile and constructs internal native data
>> 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
>> 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
>> 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
>> 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.
More information about the 2d-dev