Optimize (Linked-)HashMap lookup when backing array is null

[Christoph Dreis]

Hi,

similar to JDK-8244960[1] that I reported last week, I noticed that HashMap & LinkedHashMap could benefit from a similar improvement.

I used the following benchmark again to validate the results:


@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {

    @State(Scope.Benchmark)
    public static class ThreadState {

        private Map<TestKey, String> map = new HashMap<>();
        private TestKey key = new TestKey(Collections.singleton("test"));

        /*
        public ThreadState() {
            this.map.put(key, "test");
        }
        */
    }

    @Benchmark
    public String test(ThreadState threadState) {
        return threadState.map.get(threadState.key);
    }

}

Where TestKey is the following:

public class TestKey {

	private final Set<String> params;

	public TestKey(Set<String> params) {
		this.params = params;
	}

	@Override
	public int hashCode() {
		return this.params.hashCode();
	}

}

Applying the (hopefully) attached patch I see the following results:

Patched
Benchmark                             Mode  Cnt   Score    Error   Units
MyBenchmark.test                      avgt   10   2,717 ±  0,247   ns/op
MyBenchmark.test:·gc.alloc.rate       avgt   10  ≈ 10⁻⁴           MB/sec
MyBenchmark.test:·gc.alloc.rate.norm  avgt   10  ≈ 10⁻⁶             B/op
MyBenchmark.test:·gc.count            avgt   10     ≈ 0           counts

Old
Benchmark                             Mode  Cnt   Score    Error   Units
MyBenchmark.test                      avgt   10   3,713 ±  0,091   ns/op
MyBenchmark.test:·gc.alloc.rate       avgt   10  ≈ 10⁻⁴           MB/sec
MyBenchmark.test:·gc.alloc.rate.norm  avgt   10  ≈ 10⁻⁶             B/op
MyBenchmark.test:·gc.count            avgt   10     ≈ 0           counts

The case when the map is already filled didn't seem to show any regression.

Unfortunately, there is the caveat of potentially executing the hash() method twice in computeIfPresent if the remapping function returns null and the node is removed. I don't know if this case is really common (or more common than an empty map), but I should mention it for completeness reasons.

One common case for the above scenario is the following: I noticed that in a typical Spring-Boot app Manifest.getTrustedAttributes or Manifest.getEntries() is actually empty. Since this is used during class loading it is executed relatively frequent. I could imagine other use-cases where this might be benefitial for startup scenarios.

In case you think this is worthwhile, I would highly appreciate a sponsoring of the attached patch.

Cheers,
Christoph


[1] https://bugs.openjdk.java.net/browse/JDK-8244960


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hashmap-patch.txt
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20200519/eec8d623/hashmap-patch.txt>