RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic

[dannygonzalez]

On Thu, 16 Apr 2020 07:34:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Looking at the commit  https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd 
>>  it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` property.  Each `Node` registers itself on those and so the listener lists for those properties would scale with the number of nodes.
>> 
>> A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but I suppose it could be reproduced simply by having a large number of Nodes in a scene.  @dannygonzalez could you give us an idea how many Nodes we're talking about?  1000? 10.000?
>> 
>> It also means there might be other options, do Nodes really need to add these listeners and for which functionality and are there alternatives?  It would also be possible to target only these specific properties with an optimized listener list to reduce the impact of this change.
>
> The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and `TreeVisible`, and are used to take various decisions like whether to play/pause animations.  There is also a couple of listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`).
> 
> A lot of the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / showing status from there.  No need for so many listeners.  The other classes mentioned might register their own listener, instead of having `Node` do it for them (and thus impacting *every* node).
> 
> Alternatively, `Node` may lazily register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty specific classes only, not classes that you'd see a lot in a TableView...)

If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using 61% of the JavaFX thread whilst running our application.

[snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip)

If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to see which classes are calling the removeListener function.

![Screenshot 2020-04-16 at 09 16 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png)

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

PR: https://git.openjdk.java.net/jfx/pull/108