8263561: Re-examine uses of LinkedList #2744

stsypanov · 2021-02-26T10:48:33Z

The usage of LinkedList is senseless and can be replaced with either ArrayList or ArrayDeque which are both more compact and effective.

jdk:tier1 and jdk:tier2 are both ok

Progress

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

Issue

JDK-8263561: Re-examine uses of LinkedList

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744
$ git checkout pull/2744

Update a local copy of the PR:
$ git checkout pull/2744
$ git pull https://git.openjdk.java.net/jdk pull/2744/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2744

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/2744.diff

bridgekeeper · 2021-02-26T10:48:47Z

👋 Welcome back stsypanov! 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 · 2021-02-26T10:49:53Z

@stsypanov The following labels will be automatically applied to this pull request:

core-libs
i18n
net
nio

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

liach · 2021-02-26T15:32:57Z

Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list.

stsypanov · 2021-03-03T21:13:09Z

Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list.

As far as I know LinkedList is always worse than ArrayList and discouraged from being used.

AlanBateman · 2021-03-14T12:23:28Z

/issue JDK-8263561

openjdk · 2021-03-14T12:23:41Z

@AlanBateman Only the author (@stsypanov) is allowed to issue the /issue command.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java

stsypanov · 2021-03-14T17:05:46Z

/issue JDK-8263561

openjdk · 2021-03-14T17:06:07Z

@stsypanov The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

mlbridge · 2021-03-14T17:10:22Z

Webrevs

03: Full - Incremental (89160b3e)
02: Full - Incremental (40910fae)
01: Full - Incremental (158006c6)
00: Full (73029fe10a8a814a8c5f5221f2e667fd14a5b379)

bridgekeeper · 2021-05-06T09:16:55Z

@stsypanov 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!

stsypanov · 2021-05-06T13:45:56Z

/integrate

openjdk · 2021-05-06T13:46:39Z

@stsypanov This PR has not yet been marked as ready for integration.

stsypanov · 2021-05-21T13:13:04Z

Hi guys, any more comments here? Please ping me if I've missed something

dfuch

I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing LinkedList into ArrayList in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?

I am not convinced that a global replacement of LinkedList by ArrayList is necessarily good - even though I agree that ArrayList is generally more efficient.

dfuch · 2021-05-21T14:15:53Z

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java

-    public LinkedList<String> get(String fileName) {
-        LinkedList<String> jarFiles = null;
+    public List<String> get(String fileName) {
+        ArrayList<String> jarFiles;


This could probably be declared as:

List<String> jarFiles;

dfuch · 2021-05-21T14:18:16Z

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java

@@ -261,7 +261,7 @@ public void write(OutputStream out) throws IOException {
                /* print out the jar file name */
                String jar = jarFiles[i];
                bw.write(jar + "\n");
-                LinkedList<String> jarlist = jarMap.get(jar);
+                ArrayList<String> jarlist = jarMap.get(jar);


Here again, jarList could probably be declared as List<String>

AlanBateman · 2021-05-21T14:24:08Z

Hi guys, any more comments here? Please ping me if I've missed something

I suspect this will require renaming some fields and changing comments, e.g. requestList is no longer a good name for the field in AbstractPoller, its comments need changes too. The field in ResolverConfigurationImpl is searchList, it will require a few changes. There may be more, I just picked out a few.

Thihup · 2021-05-21T14:52:21Z

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java

@@ -151,8 +151,8 @@ private void addToList(String key, String value,
     *
     * @param fileName the key of the mapping
     */
-    public LinkedList<String> get(String fileName) {
-        LinkedList<String> jarFiles = null;
+    public List<String> get(String fileName) {


IcedTea-Web seems to be using this method reflectively:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

IcedTea-Web seems to be using this method reflectively:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

I assume this doesn't work with JDK 16, at least not without using --add-exports to export jdk.internal.util.jar.

Just for completeness, they're using the add-exports:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

Should we then revert the changes to JarIndex?

But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

I think so. There are always unexpected ways the jdk may break and third-party libraries would need a different workaround for a new java version. For instance, in Apache log4j, its library has a special guard against the broken implementation of Reflection getCallerClass during java 7. The libraries can just handle these in their version-specific components.

Especially given the fact that the code linked above already has version-specific handling (8 vs 9), so it won't hurt much for them to add another piece of logic to handle jdk 17+ in case this optimization is merged.

mcimadamore · 2021-05-21T23:16:57Z

I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly.

And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously those cases should be replaced.

stsypanov · 2021-05-25T11:36:24Z

Hi @mcimadamore, @dfuch after your review comments I've decided to do a deeper investigation for this. First, I've decided to check whether empty LinkedList is going to have smaller footprint (this could be fruitful for cases when the list is likely to remain empty in vast majority of cases, see e.g. URLClassPath.closeLoaders()), and apparently it isn't:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class EmptyListBenchmark {
    @Benchmark
    public Object emptyArrayList() { return new ArrayList<>(); }

    @Benchmark
    public Object emptyLinkedList() { return new LinkedList<>(); }
}

This benchmark with my ad-hoc JDK build yields the following results:

Benchmark                                                            Mode  Cnt     Score     Error   Units
EmptyListBenchmark.emptyArrayList                                    avgt   20     4.605 ±   0.463   ns/op
EmptyListBenchmark.emptyArrayList:·gc.alloc.rate.norm                avgt   20    24.002 ±   0.001    B/op
EmptyListBenchmark.emptyLinkedList                                   avgt   20     4.324 ±   0.081   ns/op
EmptyListBenchmark.emptyLinkedList:·gc.alloc.rate.norm               avgt   20    32.002 ±   0.001    B/op

After JDK-8011200 ArrayList instantiated with default constructor doesn't allocate underlying array any more.

However the things get more complicated when the list gets populated:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class NonEmptyListBenchmark {
    @Param({"1", "2", "3", "4", "5"})
    private int size;

    @Benchmark
    public Object arrayList() {
        var list = new ArrayList<>();
        for (int i = 0; i < size; i++) {
            list.add(i);
        }
        return list;
    }

    @Benchmark
    public Object linkedList() {
        var list = new LinkedList<Object>();
        for (int i = 0; i < size; i++) {
            list.add(i);
        }
        return list;
    }
}

Here indeed ArrayList looses in memory comapring to LinkedList in single-item case:

arrayList:·gc.alloc.rate.norm                       1  avgt   40    80.005 ±   0.001    B/op
arrayList:·gc.alloc.rate.norm                       2  avgt   40    80.006 ±   0.001    B/op
arrayList:·gc.alloc.rate.norm                       3  avgt   40    80.007 ±   0.001    B/op
arrayList:·gc.alloc.rate.norm                       4  avgt   40    80.008 ±   0.001    B/op
arrayList:·gc.alloc.rate.norm                       5  avgt   40    80.008 ±   0.001    B/op

linkedList:·gc.alloc.rate.norm                      1  avgt   40    56.004 ±   0.001    B/op
linkedList:·gc.alloc.rate.norm                      2  avgt   40    80.005 ±   0.001    B/op
linkedList:·gc.alloc.rate.norm                      3  avgt   40   104.007 ±   0.001    B/op
linkedList:·gc.alloc.rate.norm                      4  avgt   40   128.009 ±   0.001    B/op
linkedList:·gc.alloc.rate.norm                      5  avgt   40   152.010 ±   0.001    B/op

And indeed there's at least one usecase in affected files where this is real-life scenario - JarIndex. Below on screenshot I run Spring Boot tests with Gradle:

However, for the same scenario one node represented with LinkedList can hold dozens of items:

To fix this I propose to instantiate ArrayList with initial size = 1:

@Benchmark
public Object arrayList_sized() {
  var list = new ArrayList<>(1);
  list.add(new Object());
  return list;
}

This reduces the footprint of a list with 1 element down to 48 bytes:

arrayList_sized:·gc.alloc.rate.norm                      1  avgt   40    48.004 ±   0.001    B/op

Taking this into account for the files affected we can draw the following conclusions:

ProxyGenerator: list is instantiated with default constructor and is likely to remain empty or hold 1 item (exception is thrown otherwise), so it's reasonable to pass 1 into constructor
ResourceBundle: quite a rare use-case for Norwegian language, I think we can keep default constructor. For getResource() by default list with three items is returned ("en_US", "en", ""), keep default constructor
URLClassPath: bound to JarIndex, list not directly instantiated
JarIndex: sized constructor in addToList, default one elsewhere

openjdk bot added nio nio-dev@openjdk.org core-libs core-libs-dev@openjdk.org net net-dev@openjdk.org i18n i18n-dev@openjdk.org labels Feb 26, 2021

y1yang0 reviewed Mar 14, 2021

View reviewed changes

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java Show resolved Hide resolved

openjdk bot changed the title ~~Remove remaining usages of LinkedList in java.base~~ 8263561: Re-examine uses of LinkedList Mar 14, 2021

openjdk bot added the rfr Pull request is ready for review label Mar 14, 2021

dfuch reviewed May 21, 2021

View reviewed changes

Thihup reviewed May 21, 2021

View reviewed changes

stsypanov added 3 commits May 24, 2021 10:14

8263561: Re-examine uses of LinkedList

89fb009

8263561: Rename requestList -> requests

6e4dcf7

8263561: Use interface List instead of particular type where possible

158006c

stsypanov force-pushed the purge-linked-list branch from 73029fe to 158006c Compare May 25, 2021 07:24

8263561: Use sized constructor where reasonable

40910fa

Merge branch 'master' into purge-linked-list

89160b3

stsypanov closed this Jun 2, 2021

stsypanov deleted the purge-linked-list branch June 2, 2021 12:04

stsypanov restored the purge-linked-list branch June 2, 2021 12:04

stsypanov deleted the purge-linked-list branch June 2, 2021 12:04

stsypanov mentioned this pull request Jun 2, 2021

8263561: Re-examine uses of LinkedList #4304

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8263561: Re-examine uses of LinkedList #2744

8263561: Re-examine uses of LinkedList #2744

stsypanov commented Feb 26, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented Feb 26, 2021

openjdk bot commented Feb 26, 2021

liach commented Feb 26, 2021

stsypanov commented Mar 3, 2021

AlanBateman commented Mar 14, 2021 •

edited

Loading

openjdk bot commented Mar 14, 2021

stsypanov commented Mar 14, 2021

openjdk bot commented Mar 14, 2021

mlbridge bot commented Mar 14, 2021 •

edited

Loading

bridgekeeper bot commented May 6, 2021

stsypanov commented May 6, 2021

openjdk bot commented May 6, 2021

stsypanov commented May 21, 2021

dfuch left a comment

dfuch May 21, 2021

stsypanov May 24, 2021

dfuch May 21, 2021

stsypanov May 24, 2021

AlanBateman commented May 21, 2021

Thihup May 21, 2021

AlanBateman May 21, 2021 •

edited

Loading

Thihup May 21, 2021

stsypanov May 24, 2021

liach May 24, 2021

stsypanov May 24, 2021

liach May 24, 2021

mcimadamore commented May 21, 2021

stsypanov commented May 25, 2021 •

edited

Loading

8263561: Re-examine uses of LinkedList #2744

8263561: Re-examine uses of LinkedList #2744

Conversation

stsypanov commented Feb 26, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewing

bridgekeeper bot commented Feb 26, 2021

openjdk bot commented Feb 26, 2021

liach commented Feb 26, 2021

stsypanov commented Mar 3, 2021

AlanBateman commented Mar 14, 2021 • edited Loading

openjdk bot commented Mar 14, 2021

stsypanov commented Mar 14, 2021

openjdk bot commented Mar 14, 2021

mlbridge bot commented Mar 14, 2021 • edited Loading

Webrevs

bridgekeeper bot commented May 6, 2021

stsypanov commented May 6, 2021

openjdk bot commented May 6, 2021

stsypanov commented May 21, 2021

dfuch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlanBateman commented May 21, 2021

Choose a reason for hiding this comment

AlanBateman May 21, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcimadamore commented May 21, 2021

stsypanov commented May 25, 2021 • edited Loading

stsypanov commented Feb 26, 2021 •

edited by openjdk bot

Loading

AlanBateman commented Mar 14, 2021 •

edited

Loading

mlbridge bot commented Mar 14, 2021 •

edited

Loading

AlanBateman May 21, 2021 •

edited

Loading

stsypanov commented May 25, 2021 •

edited

Loading