Hi Christoph,
unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty
accessors - could this be used to simplify your patch?
It's easy to get heavily biased results in microbenchmarks when all you
do is repeatedly calling down one path. That is, JIT might speculatively
assume all HashMaps are empty or non-empty if all you do is call a
method on only empty or non-empty maps respectively. So I'd like to see
some analysis on microbenchmark that uses a mix of such maps in the same
@Benchmark
/Claes
On 2020-05-19 14:22, Christoph Dreis wrote:
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
