RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v9]

[John Hendrikx]

On Wed, 1 Feb 2023 10:15:36 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
>> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269907
>   renamed testclass, based on code review,
>   readded acidentally removed import

Adding to the above, I couldn't find in what cases `Node` might be referred from `NGNode`. Where is this happening?

Further, `NGNode` only has a parent pointer, not a full parent/child hierarchy like `Parent` has.  This would mean that if you track `NGNode` in `Parent#removed` a big part of the problem is alleviated as only a few parent `NGNode` will be unable to be GC'd, versus entire UI trees when you refer to `Node`.

I also did some more digging, and the only thing that the dirty region computation for removed nodes really requires is a `RectBounds`.  To do this it accesses only a couple of fields of `NGNode`, no heavy calculations are involved in this part and so this could be done right away -- it's also possible that `Node` may already have this information in some form (basically we need to know the last bounds of the node when it was rendered on screen -- saving a copy in the `doUpdatePeer` call may be sufficient).  When the dirty area computation for the parent is performed, you'd only need to apply the transforms and clipping logic that the parent provides on this `RectBounds` -- no further fields of the removed `NGNode` would need to be accessed.

-------------

PR: https://git.openjdk.org/jfx/pull/584