8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations #1679

mstr2 · 2025-01-15T00:32:37Z

Passing a VetoableListDecorator.subList() to any of its bulk operations (addAll, setAll, removeAll, retainAll) throws ConcurrentModificationException. The reason is that the VetoableListDecorator.modCount field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation.

However, simply updating the modCount field after the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for modCount in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation.

/reviewers 2

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

JDK-8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations (Bug - P4)

Reviewers

Andy Goryachev (@andy-goryachev-oracle - Reviewer)
Kevin Rushforth (@kevinrushforth - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1679/head:pull/1679
$ git checkout pull/1679

Update a local copy of the PR:
$ git checkout pull/1679
$ git pull https://git.openjdk.org/jfx.git pull/1679/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1679

View PR using the GUI difftool:
$ git pr show -t 1679

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1679.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-01-15T00:33:12Z

👋 Welcome back mstrauss! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-01-15T00:34:08Z

@mstr2 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations

Reviewed-by: angorya, kcr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 26 new commits pushed to the master branch:

f38ab33: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6
0555fb2: 8349472: Update copyright header for files modified in 2025
163bf6d: 8350437: [GHA] Update gradle wrapper-validation action to v3
307e308: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video
ae5864c: 8349758: Memory leak in TreeTableView
065548d: 8349891: Not implemented function should have printf
d07d5cc: 8349105: Pagination: exception initializing in a background thread
01059d4: 8349255: TitledPane: exception initializing in a background thread
d1f5ea8: 8349098: TabPane: exception initializing in a background thread
b267340: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode
... and 16 more: https://git.openjdk.org/jfx/compare/a176574744978156edf8f83d8c0b2f994b36cd1c...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

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

openjdk · 2025-01-15T00:34:29Z

@mstr2
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

mlbridge · 2025-01-15T00:37:49Z

Webrevs

01: Full - Incremental (81917761)
00: Full (5ba5a110)

andy-goryachev-oracle · 2025-01-16T00:07:49Z

modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java


-    private class VetoableSubListDecorator implements List<E> {
+    /**
+     * Returns the specified collection as an unmodifiable list that can safely be used in all bulk


Do you think it might be easier to create a defensive copy always?

In other words, can we guarantee that it is impossible for the user to create a convoluted code involving maybe two VetoableListDecorators where the second one loops back the changes to the first one, however ridiculous that might sound?

The way I see it, the situation that erroneously triggers ConcurrentModificationException only happens when VetoableListDecorator accesses its own sublist:

try { modCount++; boolean ret = list.addAll(index, c); // --> c is its own sublist ...

Since modCount is modified first, and the sublist refers back to the same modified modCount, the exception occurs. It can't occur when we are dealing with another list (or a sublist of another list), since in this case there is no self-referential conflict.

The way ArrayList circumvents this problem is by incrementing modCount only after the operation is done, not before it has started; it doesn't create a defensive copy.

Thank you for clarification! I'll try to come up with a test (and I think even if I succeed, it does not mean that your solution is not good, since the caller can always create a defensive copy themselves).

BTW, what were you doing to trigger this bug?

BTW, what were you doing to trigger this bug?

This happened when I was writing some tests for the other VetoableListDecorator PRs...

andy-goryachev-oracle

The scenario I was referring to is impossible, I think.

One possible alternative is to create the defensive copy each time, this will save one extra pointer every time an iterator or a sublist gets created (these objects might be long lived). The code in this PR creates a copy in many (most?) cases anyway, and in my opinion, the memory is more precious resource that CPU cycles (i.e. using extra memory costs many more CPU cycles in garbage collection etc.), so please consider that.

some minor suggestions

andy-goryachev-oracle · 2025-01-16T18:17:13Z

modules/javafx.base/src/test/java/test/javafx/collections/VetoableObservableListTest.java

+    public void testAddAll_subList() {
+        list.addAll(list.subList(0, 2));
+        assertSingleCall(new String[] {"foo", "bar"}, new int[] {4, 4});
+    }


suggestion: also check that the list contains the newly added elements?
(here and in added tests that involve subList?)

I've added checks for the list content in all modified tests.

mstr2 · 2025-01-27T18:34:14Z

One possible alternative is to create the defensive copy each time, this will save one extra pointer every time an iterator or a sublist gets created (these objects might be long lived). The code in this PR creates a copy in many (most?) cases anyway, and in my opinion, the memory is more precious resource that CPU cycles (i.e. using extra memory costs many more CPU cycles in garbage collection etc.), so please consider that.

I don't quite understand what you mean. Can you elaborate?
In particular, what does "save one extra pointer" mean?

andy-goryachev-oracle · 2025-01-27T18:47:41Z

Can you elaborate?
what does "save one extra pointer" mean?

What I mean is simply get rid of the extra pointer like VetoableListIteratorDecorator.parent and the related logic, and simply create a copy of List/Collection each time.

mstr2 · 2025-01-27T18:55:11Z

Can you elaborate?
what does "save one extra pointer" mean?

What I mean is simply get rid of the extra pointer like VetoableListIteratorDecorator.parent and the related logic, and simply create a copy of List/Collection each time.

Okay, I see. We can't do that, because a sublist is specified to be a live view onto the source list. After all, list.subList(0, 3).clear() is valid code, and the result is that three elements are removed from the source list.

andy-goryachev-oracle · 2025-01-27T19:02:57Z

We can't do that, because a sublist is specified to be a live view onto the source list.

good point, thanks for pointing this out.

andy-goryachev-oracle

lgtm

bridgekeeper · 2025-02-24T22:21:17Z

@mstr2 This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

kevinrushforth

Code changes look good. I confirm that the new tests fail without the fix and pass with the fix.

mstr2 · 2025-02-25T17:54:59Z

/integrate

openjdk · 2025-02-25T17:55:19Z

Going to push as commit 4f0f992.
Since your change was applied there have been 26 commits pushed to the master branch:

f38ab33: 8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6
163bf6d: 8350437: [GHA] Update gradle wrapper-validation action to v3
307e308: 8337960: Improve performance of mfwrapper by reusing GStreamer media buffers for decoded video
ae5864c: 8349758: Memory leak in TreeTableView
065548d: 8349891: Not implemented function should have printf
d07d5cc: 8349105: Pagination: exception initializing in a background thread
01059d4: 8349255: TitledPane: exception initializing in a background thread
d1f5ea8: 8349098: TabPane: exception initializing in a background thread
b267340: 8348095: [Linux] Menu shows up in wrong position when using i3 windows manager in full screen mode
... and 16 more: https://git.openjdk.org/jfx/compare/a176574744978156edf8f83d8c0b2f994b36cd1c...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-02-25T17:55:31Z

@mstr2 Pushed as commit 4f0f992.

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

mstr2 added 2 commits January 15, 2025 00:52

failing tests

e0e84ff

allow sublists to be used for bulk operations

5ba5a11

openjdk bot added the rfr Ready for review label Jan 15, 2025

andy-goryachev-oracle reviewed Jan 16, 2025

View reviewed changes

kevinrushforth self-requested a review January 23, 2025 17:17

mstr2 added 4 commits January 27, 2025 19:21

Merge branch 'master' into fixes/vetoable-list-decorator-sublist

9384b36

check list content in tests

3090a10

update tests

ece236b

update tests

8191776

andy-goryachev-oracle approved these changes Jan 27, 2025

View reviewed changes

kevinrushforth approved these changes Feb 25, 2025

View reviewed changes

openjdk bot added the ready Ready to be integrated label Feb 25, 2025

openjdk bot added the integrated Pull request has been integrated label Feb 25, 2025

openjdk bot closed this Feb 25, 2025

openjdk bot removed ready Ready to be integrated rfr Ready for review labels Feb 25, 2025

mstr2 deleted the fixes/vetoable-list-decorator-sublist branch July 26, 2025 20:43

8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations #1679

8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations #1679

Uh oh!

Conversation

mstr2 commented Jan 15, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jan 15, 2025

Uh oh!

openjdk bot commented Jan 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Jan 15, 2025

Uh oh!

mlbridge bot commented Jan 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

andy-goryachev-oracle Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

mstr2 Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

andy-goryachev-oracle Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

mstr2 Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

andy-goryachev-oracle left a comment

Choose a reason for hiding this comment

Uh oh!

andy-goryachev-oracle Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

mstr2 Jan 27, 2025

Choose a reason for hiding this comment

Uh oh!

mstr2 commented Jan 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andy-goryachev-oracle commented Jan 27, 2025

Uh oh!

mstr2 commented Jan 27, 2025

Uh oh!

andy-goryachev-oracle commented Jan 27, 2025

Uh oh!

andy-goryachev-oracle left a comment

Choose a reason for hiding this comment

Uh oh!

bridgekeeper bot commented Feb 24, 2025

Uh oh!

kevinrushforth left a comment

Choose a reason for hiding this comment

Uh oh!

mstr2 commented Feb 25, 2025

Uh oh!

openjdk bot commented Feb 25, 2025

Uh oh!

openjdk bot commented Feb 25, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

mstr2 commented Jan 15, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Jan 15, 2025 •

edited

Loading

mlbridge bot commented Jan 15, 2025 •

edited

Loading

mstr2 commented Jan 27, 2025 •

edited

Loading