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

[dannygonzalez]

On Thu, 16 Apr 2020 08:46:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> 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)
>
> @dannygonzalez  Could you perhaps debug your application and take a look at how large the following array is: a random node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`.  I just tested this with a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw about 20000 change listeners registered on this single Scene Window property.
> 
> However, this custom control is not creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going on, scrolling was still smooth >30 fps.

@hjohn I have 12136 change listeners when debugging our application as you suggested.

Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I do not see the issue.

It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered.
The Visual VM snapshot I attached above was taken as our application was adding items to the TableView.

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

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