8246745: ListCell/Skin: misbehavior on switching skin #251

kleopatra · 2020-06-10T12:25:04Z

ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the listView and incorrect update of internal state (see bug report for details)

Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView state when needed.

Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior before/after.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8246745: ListCell/Skin: misbehavior on switching skin

Reviewers

Kevin Rushforth (@kevinrushforth - Reviewer)
Ambarish Rapte (@arapte - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jfx pull/251/head:pull/251
$ git checkout pull/251

bridgekeeper · 2020-06-10T12:25:28Z

👋 Welcome back fastegal! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request.

mlbridge · 2020-06-10T12:35:58Z

Webrevs

01: Full - Incremental (75c209a)
00: Full (c21ed22)

kevinrushforth · 2020-06-10T23:33:46Z

@arapte can you review?

arapte · 2020-06-15T06:25:36Z

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListCellSkin.java

    @Override protected double computePrefHeight(double width, double topInset, double rightInset, double bottomInset, double leftInset) {
-        if (fixedCellSizeEnabled) {
+        double fixedCellSize = getFixedCellSize();
+        if (fixedCellSize > 0) {


These compute methods get invoked multiple times during each layout pass(10s of times). Fetching the fixed cell size on each call to these methods seems to be repeated and costly operation compared to previous boolean check. I think we should keep the previous way of handling it: registering the change listener to listView.fixedCellSizeProperty().

ehh .. last time I did such micro-optimization was in the 80ies of last century ;)

Are there any performance measurements anywhere to demonstrate the impact?

a bit less flippant: really interested in the measurements - certainly, they are somewhere but can't find anything. Any pointer where to look?

Even I do not know if there are any performance measurements for such scenario. :) May be @kevinrushforth could help in that.
I just counted the calls by adding a log, and observed that for a ListView with only one item, these three methods combinely are called 23 times when the Stage is displayed for the first time and 5 times when the item is selected. (updated the counts after rechecking, looks like the methods are invoked for empty cells too, which seems correct)

hmm, do you mean a list with height of one cell only?

My experiment (having counters per instance and per computeXXHeight), logs 1 (or 2) for computePref with fixed size and 5 (1 each for min/max and 3 for pref) without fixedSize per layout pass. So it's 5* access of either the local field or the listView method .. wouldn't expect any problems, but then assumed performance is reading in coffee ground :)

Let's hope there are some metrics to use :)

hmm, do you mean a list with height of one cell only?

Yes, List with one cell height.
In continuation to my previous comment, looks like 8 of the first 23 calls when window is displayed for the first time are NOT for the one visible cell. These 8 calls are for some intermediate cell.
I added a single counter for all three computeXXHeight methods and verified with a list of height of one cell.
When fixedCellSize is not set, total combined number of calls for a cell are,

15, when Stage is displayed for the first time.(+8 for an intermediate cell, not sure why)

5, when the list item is selected.

5, when the Window is resized.

something similar as I'm seeing - that's good :) Uploaded my play code to gist: the idea is to do something (like f.i. moving the selection), then press f1 to log the calls to each cell (the skin has a final instance counter and counters for calling the compute methods).

As much fun as this is (really like to dig until I'm dirty all over :) - at the end of the day we'll need some measurements (doing these is not so much fun, still hoping something already available)

Normally we implement this sort of lazy evaluation (caching + invalidation) when there is a computation that is being saved, or when a micro-benchmark shows that something is called 1000s of times (e.g., in the inner loop of some common operation).

I don't see either being the case here, but it's possible I missed something. The method in question, getFixedCellSize() just calls ListView::getFixedCellSize which just returns the value of a property. I suspect that any performance hit would be down in the noise.

So I think the complexity of the existing mechanism isn't justified. Removing the listener as the PR proposes to do, which is possible since the listener isn't being used to trigger an operation, seems like a win as well.

I am inclined to approve this fix even without performance measurements, since it seems unlikely they would show a problem.

@arapte if you want to measure it further before you approve it, that would be fine.

The few additional computation would not cause any harm to performance. It just increases few computations in the compute* methods. Just for sanity verified a program with ListView of 10000000. ListView gets scrolled just as smooth.
Approving.

kleopatra · 2020-06-26T10:44:11Z

Hmm .. bottleneck seems to be layout as such (including css), accessing an instance field vs. querying a property doesn't make a difference (at least none I could see).

kevinrushforth · 2020-07-22T16:24:59Z

/reviewers 2

openjdk · 2020-07-22T16:25:32Z

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

kevinrushforth

(catching up on some overdue reviews)

The fix and tests look fine to me. I left one minor suggestion to add a comment in one of the tests.

kevinrushforth · 2020-09-10T17:10:41Z

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListCellSkin.java

    @Override protected double computePrefHeight(double width, double topInset, double rightInset, double bottomInset, double leftInset) {
-        if (fixedCellSizeEnabled) {
+        double fixedCellSize = getFixedCellSize();
+        if (fixedCellSize > 0) {


Normally we implement this sort of lazy evaluation (caching + invalidation) when there is a computation that is being saved, or when a micro-benchmark shows that something is called 1000s of times (e.g., in the inner loop of some common operation).

I don't see either being the case here, but it's possible I missed something. The method in question, getFixedCellSize() just calls ListView::getFixedCellSize which just returns the value of a property. I suspect that any performance hit would be down in the noise.

So I think the complexity of the existing mechanism isn't justified. Removing the listener as the PR proposes to do, which is possible since the listener isn't being used to trigger an operation, seems like a win as well.

I am inclined to approve this fix even without performance measurements, since it seems unlikely they would show a problem.

@arapte if you want to measure it further before you approve it, that would be fine.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java

openjdk · 2020-09-11T12:03:43Z

@kleopatra This change now passes all automated pre-integration checks. In addition to the automated checks, the change must also fulfill all project specific requirements

After integration, the commit message will be:

8246745: ListCell/Skin: misbehavior on switching skin

Reviewed-by: kcr, arapte

If you would like to add a summary, use the /summary command.
To credit additional contributors, use the /contributor command.
To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there have been 74 commits pushed to the master branch:

7506554: Merge
4b75750: 8252784: Create release notes for JavaFX 15 (8252784: Create release notes for JavaFX 15 #296)
3cb3ca8: 8202990: javafx webview css filter property with display scaling
a5ecfb6: 8252387: Deprecate for removal css Selector and ShapeConverter constructors
8e3616c: 8252062: WebKit build fails with recent VS 2019 compiler
87ad57f: 8251858: Update to Xcode 11.3.1
88c0f97: 8252381: Cherry pick GTK WebKit 2.28.4 changes
c86bd35: 8251941: ListCell: visual artifact when items contain null values
23ad8f4: 8251353: Many javafx scenegraph classes have implicit no-arg constructors
7a4bd9b: 8252060: gstreamer fails to build with gcc 10
... and 64 more: https://git.openjdk.java.net/jfx/compare/afa805fe8b87f6d9bda60b69e9365ea521439cb7...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge master into your branch, and then specify the current head hash when integrating, like this: /integrate 75065542aaf6fd8acdaf287e52ab146fc0a9f947.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

kleopatra · 2020-09-11T12:20:36Z

/integrate

openjdk · 2020-09-11T12:21:37Z

@kleopatra Since your change was applied there have been 74 commits pushed to the master branch:

7506554: Merge
4b75750: 8252784: Create release notes for JavaFX 15 (8252784: Create release notes for JavaFX 15 #296)
3cb3ca8: 8202990: javafx webview css filter property with display scaling
a5ecfb6: 8252387: Deprecate for removal css Selector and ShapeConverter constructors
8e3616c: 8252062: WebKit build fails with recent VS 2019 compiler
87ad57f: 8251858: Update to Xcode 11.3.1
88c0f97: 8252381: Cherry pick GTK WebKit 2.28.4 changes
c86bd35: 8251941: ListCell: visual artifact when items contain null values
23ad8f4: 8251353: Many javafx scenegraph classes have implicit no-arg constructors
7a4bd9b: 8252060: gstreamer fails to build with gcc 10
... and 64 more: https://git.openjdk.java.net/jfx/compare/afa805fe8b87f6d9bda60b69e9365ea521439cb7...master

Your commit was automatically rebased without conflicts.

Pushed as commit 0514116.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8246745: ListCell/Skin: misbehavior on switching skin

c21ed22

openjdk bot added the rfr Ready for review label Jun 10, 2020

arapte reviewed Jun 15, 2020

View reviewed changes

kevinrushforth self-requested a review July 22, 2020 16:25

kevinrushforth approved these changes Sep 10, 2020

View reviewed changes

added code comment as requested in review

75c209a

kevinrushforth approved these changes Sep 11, 2020

View reviewed changes

arapte approved these changes Sep 11, 2020

View reviewed changes

openjdk bot added the ready Ready to be integrated label Sep 11, 2020

openjdk bot closed this Sep 11, 2020

openjdk bot added integrated Pull request has been integrated and removed ready Ready to be integrated rfr Ready for review labels Sep 11, 2020

kleopatra deleted the bug-fix-8246745 branch September 11, 2020 12:33

8246745: ListCell/Skin: misbehavior on switching skin #251

8246745: ListCell/Skin: misbehavior on switching skin #251

Uh oh!

Conversation

kleopatra commented Jun 10, 2020 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Download

Uh oh!

bridgekeeper bot commented Jun 10, 2020

Uh oh!

mlbridge bot commented Jun 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

kevinrushforth commented Jun 10, 2020

Uh oh!

arapte Jun 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kleopatra Jun 15, 2020

Choose a reason for hiding this comment

Uh oh!

kleopatra Jun 15, 2020

Choose a reason for hiding this comment

Uh oh!

arapte Jun 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kleopatra Jun 15, 2020

Choose a reason for hiding this comment

Uh oh!

arapte Jun 16, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kleopatra Jun 16, 2020

Choose a reason for hiding this comment

Uh oh!

kevinrushforth Sep 10, 2020

Choose a reason for hiding this comment

Uh oh!

arapte Sep 11, 2020

Choose a reason for hiding this comment

Uh oh!

kleopatra commented Jun 26, 2020

Uh oh!

kevinrushforth commented Jul 22, 2020

Uh oh!

openjdk bot commented Jul 22, 2020

Uh oh!

kevinrushforth left a comment

Choose a reason for hiding this comment

Uh oh!

kevinrushforth Sep 10, 2020

Choose a reason for hiding this comment

Uh oh!

Uh oh!

openjdk bot commented Sep 11, 2020

Uh oh!

kleopatra commented Sep 11, 2020

Uh oh!

openjdk bot commented Sep 11, 2020

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

kleopatra commented Jun 10, 2020 •

edited by openjdk bot

Loading

mlbridge bot commented Jun 10, 2020 •

edited

Loading

arapte Jun 15, 2020 •

edited

Loading

arapte Jun 15, 2020 •

edited

Loading

arapte Jun 16, 2020 •

edited

Loading