> 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
On Fri, 2 Feb 2024 17:38:13 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 maps.
>>
>> I used the comman
On Thu, 8 Feb 2024 17:01:15 GMT, Joshua Cao wrote:
>> I think we should step back from benchmarks a bit and examine the various
>> tradeoffs occurring here. Certainly we can speed things up by pre-resizing
>> the map to be larger. However, this can result in a map that is too large
>> for the
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 examine the various
> tradeoffs occurrin
On Fri, 2 Feb 2024 17:38:13 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 maps.
>>
>> I used the comman
> 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
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 non-po
On Sat, 27 Jan 2024 21:58:05 GMT, Joshua Cao wrote:
>> src/java.base/share/classes/java/util/HashMap.java line 503:
>>
>>> 501: */
>>> 502: final void putMapEntries(Map m, boolean
>>> evict) {
>>> 503: int s = Math.max(size() + m.size(), m.size());
>>
>> If we decide this appr
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/classes/java/util/HashMap.java line
On Thu, 25 Jan 2024 00:29:40 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 maps.
>>
>> I used the comma
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) size
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 maps.
>>
>> I used the comma
> 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
On Wed, 24 Jan 2024 21:53:51 GMT, Hannes Greule wrote:
>...then suggest we should change the Map::size() api to return a long...
For any Map/Collection you can fetch the Spliterator and use estimateSize or
getExactSizeIfKnown as both return size as a long.
-
PR Comment: https://gi
On Wed, 24 Jan 2024 20:54:43 GMT, Joshua Cao 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 chang
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` (i
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 n
> 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
On Wed, 24 Jan 2024 00:26:09 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 maps.
>
> I used the command be
On Wed, 24 Jan 2024 00:26:09 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 maps.
>
> I used the command be
On Wed, 24 Jan 2024 00:26:09 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 maps.
>
> I used the command be
On Wed, 24 Jan 2024 00:26:09 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 maps.
>
> I used the command be
22 matches
Mail list logo
