unt 10 HASH_MAP
> 10 avgt ≈ 0 counts
> HashMapBench.putAllSameKeys10 LINKED_HASH_MAP
> 10 avgt 8.417 ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate 10 LINKED_
On Fri, 5 Apr 2024 15:57:24 GMT, Volker Simonis wrote:
>> I tried looking at the docs with `make docs-image`, but I can't test that
>> the syntax/links are actually correct because `@implNote` does not actually
>> show up in the web pages. As I understand from [the original
>>
On Thu, 4 Apr 2024 22:17:33 GMT, Joshua Cao wrote:
>> Add notes for `HashMap::putAll()` conservative resizing.
>>
>> Note: everything below this line is from the original change. After
>> discussion, we decided to keep the conservative resizing, but we shou
unt 10 HASH_MAP
> 10 avgt ≈ 0 counts
> HashMapBench.putAllSameKeys10 LINKED_HASH_MAP
> 10 avgt 8.417 ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate 10 LINKED_
On Fri, 9 Feb 2024 14:05:56 GMT, Volker Simonis wrote:
>> Joshua Cao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> extract msize variable
>
> I agree that a comment would be helpful but I'm afraid that
unt 10 HASH_MAP
> 10 avgt ≈ 0 counts
> HashMapBench.putAllSameKeys10 LINKED_HASH_MAP
> 10 avgt 8.417 ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate 10 LINKED_
10 LINKED_HASH_MAP
> 10 avgt 992.543 MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm 10 LINKED_HASH_MAP
> 10 avgt 8768892.941B/op
> HashMapBench.putAllSameKeys:gc.count 100000 LINKED_HASH_MAP
>
On Fri, 2 Feb 2024 17:38:13 GMT, Joshua Cao wrote:
>> Add notes for `HashMap::putAll()` conservative resizing.
>>
>> Note: everything below this line is from the original change. After
>> discussion, we decided to keep the conservative resizing, but we shou
On Wed, 7 Feb 2024 20:50:57 GMT, Stuart Marks wrote:
>> Joshua Cao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> extract msize variable
>
> I think we should step back from benchmarks a bit and ex
10 LINKED_HASH_MAP
> 10 avgt 992.543 MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm 10 LINKED_HASH_MAP
> 10 avgt 8768892.941B/op
> HashMapBench.putAllSameKeys:gc.count 100000 LINKED_HASH_MAP
>
On Fri, 2 Feb 2024 04:51:33 GMT, jmehrens wrote:
> Circling back to "the case where many keys exist in both maps". What are your
> thoughts on some optimized variant/refactoring of:
int s = Math.max(m.size() - this.size(), 1);
Calling `Math.max` is unnecessary here. Its ok if `s` ends up
On Sat, 27 Jan 2024 09:09:26 GMT, Ismael Juma wrote:
>> Joshua Cao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use max of both sizes and other maps size in case of overflow
>
> src/java.base/share/class
On Wed, 24 Jan 2024 23:53:34 GMT, jmehrens wrote:
> For any Map/Collection you can fetch the Spliterator and use estimateSize or
> getExactSizeIfKnown as both return size as a long.
Based on the code, I think this will just return the original size. It would be
the same as casting `(long)
On Wed, 24 Jan 2024 20:40:36 GMT, Joshua Cao wrote:
>> This change mirrors what we did for ConcurrentHashMap in
>> https://github.com/openjdk/jdk/pull/17116. When we add all entries from one
>> map to anther, we should resize that map to the size of the sum of both m
10 LINKED_HASH_MAP
> 10 avgt 992.543 MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm 10 LINKED_HASH_MAP
> 10 avgt 8768892.941B/op
> HashMapBench.putAllSameKeys:gc.count 100000 LINKED_HASH_MAP
>
On Wed, 24 Jan 2024 19:55:27 GMT, Chen Liang wrote:
> Then we might need some statistics on how often `putAll` replaces existing
> mappings, ranging from none at all to completely. For example,
> `Collectors.toMap` would never replace existing mappings, even though it
> doesn't use `putAll`
On Wed, 24 Jan 2024 19:06:49 GMT, Volker Simonis wrote:
> The current benchmark and the change don't really cover the case where many
> keys exist in _both_ maps. Could you add a benchmark for that?
I added a benchmark that assumes the worse case. Please see the top post. Yes,
this change is
(addSize)(mapType) (size) Mode Cnt Score
> Error Units
> HashMapBench.putAll 10 HASH_MAP 10 avgt4 16.780 ±
> 0.526 ms/op
> HashMapBench.putAll 10 LINKED_HASH_MAP 10 avgt4 19.721 ±
> 0.349 ms/op
>
>
> We see
On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao wrote:
> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
> `transfer()`. When coming from the copy constructor, the Map is empty, so
> there is nothing to transfer. But `transfer()` will still copy all the
This change mirrors what we did for ConcurrentHashMap in
https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map
to anther, we should resize that map to the size of the sum of both maps.
I used the command below to run the benchmarks. I set a high heap to reduce
garbage
On Mon, 22 Jan 2024 17:45:45 GMT, Volker Simonis wrote:
>> Joshua Cao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> putAll presize based on sum on both map sizes
>
> test/micro/org/openjdk/bench/java/util
org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
> 3006955.723 ±(99.9%) 271757.969 ns/op [Average]
> (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev =
> 254202.573
> CI (99.9%): [2735197.754, 3278713.692] (assumes normal distribution)
On Thu, 18 Jan 2024 07:17:20 GMT, ExE Boss wrote:
>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line
>> 1088:
>>
>>> 1086: public void putAll(Map m) {
>>> 1087: if (table != null) {
>>> 1088: tryPresize(size() + m.size());
>>
>> Is overflow
On Fri, 12 Jan 2024 08:51:16 GMT, Volker Simonis wrote:
>>> tryPresize(int size) is doing and if its size argument is supposed to
>>> contain the additional number of elements which will be inserted into the
>>> hash map or if it is a hint for the new total size of the hash map
>>
>> Argument
org.openjdk.bench.java.util.concurrent.Maps.testConcurrentHashMapPutAll":
> 3006955.723 ±(99.9%) 271757.969 ns/op [Average]
> (min, avg, max) = (2801264.198, 3006955.723, 3553084.135), stdev =
> 254202.573
> CI (99.9%): [2735197.754, 3278713.692] (assumes normal dist
On Thu, 11 Jan 2024 09:40:07 GMT, Volker Simonis wrote:
> tryPresize(int size) is doing and if its size argument is supposed to contain
> the additional number of elements which will be inserted into the hash map or
> if it is a hint for the new total size of the hash map
Argument `size` for
On Mon, 8 Jan 2024 15:59:17 GMT, Volker Simonis wrote:
> Shouldn't this be something like tryPresize(this.size() + m.size()) to
> accommodate for the worst case where there are no common keys in this map and
> m?
Its a good callout. Not sure if it is a miss, or intentionally conservative.
>
On Wed, 3 Jan 2024 19:52:34 GMT, Joshua Cao wrote:
>> test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122:
>>
>>> 120: public void testCopyConstructor() {
>>> 121: ConcurrentHashMap clone = new
>>> ConcurrentHashMap<&g
36470.010] (assumes normal distribution)
>
>
> after patch:
>
>
> Result "org.openjdk.bench.java.util.concurrent.Maps.testCopyConstructor":
> 620871.469 ±(99.9%) 59195.406 ns/op [Average]
> (min, avg, max) = (545304.633, 620871.469, 689013.573), stdev = 55371.419
> CI (99.9%): [
On Wed, 3 Jan 2024 14:34:50 GMT, Aleksey Shipilev wrote:
>> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
>> `transfer()`. When coming from the copy constructor, the Map is empty, so
>> there is nothing to transfer. But `transfer()` will still copy all the empty
ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
`transfer()`. When coming from the copy constructor, the Map is empty, so there
is nothing to transfer. But `transfer()` will still copy all the empty nodes
from the old table to the new table.
This patch avoids this
31 matches
Mail list logo
