Changes are fine. Thanks, Jay
> On 11-Oct-2019, at 2:01 PM, Philip Race <philip.r...@oracle.com> 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 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. > > > >
