On Thu, 10 Feb 2022 17:46:36 GMT, XenoAmess wrote:
> 8281631: HashMap.putAll can cause redundant space waste
According to the discussion at mailing list, we decide to try only change the
calculation inside HashMap and WeakHashMap, and see what would happen.
The next step is fixing all s
8281631: HashMap.putAll can cause redundant space waste
-
Commit messages:
- 9072610: HashMap.putAll can cause redundant space waste
Changes: https://git.openjdk.java.net/jdk/pull/7431/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=00
Issue: https://bugs.o
On Fri, 11 Feb 2022 11:55:13 GMT, stefan-zobel wrote:
> > I investigated most of the usages. They just give a size, and get a
> > capacity, even not change the 0.75 So maybe we can use some int calculation
> > to replace the 0.75, thus replace Math.ceil for such situations.
>
> FWIW, `(int) Ma
> 8281631: HashMap.putAll can cause redundant space waste
XenoAmess has refreshed the contents of this pull request, and previous commits
have been removed. The incremental views will show differences compared to the
previous content of the PR. The pull request contains one new commit since
> 8281631: HashMap.putAll can cause redundant space waste
XenoAmess has refreshed the contents of this pull request, and previous commits
have been removed. The incremental views will show differences compared to the
previous content of the PR. The pull request contains one new commit since
On Fri, 11 Feb 2022 15:04:03 GMT, Roger Riggs wrote:
> if size were Integer.MAX_VALUE / 2; the computation would overflow
Actually will not, it must be slightly larger. it will only overflow when it be
larger than Integer.MAX_VALUE * 0.75
But yes, it can overflow when there be a map as large a
> 8281631: HashMap.putAll can cause redundant space waste
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
9072610: HashMap.putAll can cause redundant space waste
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Fri, 11 Feb 2022 15:04:03 GMT, Roger Riggs wrote:
>> XenoAmess has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains
> 8281631: HashMap.putAll can cause redundant space waste
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
9072610: HashMap.putAll can cause redundant space waste
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Fri, 11 Feb 2022 16:32:29 GMT, Roger Riggs wrote:
>> @RogerRiggs
>>
>> Hi. I added a overflow check.
>>
>> The check makes sure it cannot overflow now.
>>
>> I wrote a test to show this overflow check be correct.
>>
>>
>> public class A {
>>
>> /**
>> * use for calculate HashMap
On Fri, 11 Feb 2022 17:10:43 GMT, XenoAmess wrote:
>> 8281631: HashMap.putAll can cause redundant space waste
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 9072610: HashMap.putAll can cause redundant
On Fri, 11 Feb 2022 18:42:11 GMT, Stuart Marks wrote:
> (It's too late now, but I'd suggest avoiding force-pushing changes into a
> branch that's opened in a PR. Doing so confuses the comment history, as the
> comments refer to code that is no longer present.)
got it.
-
PR: https
On Fri, 11 Feb 2022 18:24:49 GMT, Andrew Haley wrote:
> Just multiply by 0.75.
>
> On a modern design, floating-point multiply is 4 clocks latency, 4 ops/clock
> throughput. FP max is 2 clocks latency, conversions int-float and vice versa
> 3 clocks latency, 4 ops/clock throughput. Long divisi
On Fri, 11 Feb 2022 18:40:53 GMT, Stuart Marks wrote:
> Let's stick with the `Math.ceil` expression please.
I'm afraid Math.ceil is much too time costing, but fine if you want.
-
PR: https://git.openjdk.java.net/jdk/pull/7431
> 8281631: HashMap.putAll can cause redundant space waste
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
9072610: HashMap.putAll can cause redundant space waste
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Tue, 15 Feb 2022 02:00:35 GMT, Stuart Marks wrote:
> The changes to j.l.Class and the EnumConstantDirectory test don't belong here
> -- these are _uses_ of HashMap. This bug and fix should focus on HashMap
> itself, to ensure that the cases in question allocate a table of the right
> size.
On Tue, 15 Feb 2022 03:45:19 GMT, Stuart Marks wrote:
> > A test will fail if not change codes there. Every pr should pass ci, so I
> > have no choice.
>
> Hm, yes I recall in the preliminary email that there was some mention of a
> test. However, the test seemed to use the same (incorrect) ca
> 8281631: HashMap.putAll can cause redundant space waste
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
9072610: HashMap.putAll can cause redundant space waste
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
9072610: HashMap.putAll can cause redundant space waste
-
Changes:
- all: ht
On Tue, 15 Feb 2022 16:58:49 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 9072610: HashMap.putAll can
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
9072610: HashMap copy constructor and putAll can over-allocate table
-
Changes:
- all: ht
On Tue, 15 Feb 2022 18:23:51 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 9072610: HashMap copy constructo
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with two additional
commits since the last revision:
- revert changes in ConcurrentHashMap
- 9072610: HashMap copy constructor and putAll can over-allocate ta
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
fix test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
fix test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
fix test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
fix test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Tue, 15 Feb 2022 03:45:19 GMT, Stuart Marks wrote:
>>> The changes to j.l.Class and the EnumConstantDirectory test don't belong
>>> here -- these are _uses_ of HashMap. This bug and fix should focus on
>>> HashMap itself, to ensure that the cases in question allocate a table of
>>> the righ
On Thu, 17 Feb 2022 05:45:54 GMT, Stuart Marks wrote:
> It's not clear to me that test is actually testing anything useful; it's just
> testing the same computation a couple different ways.
Well if I don't change it, then the test will fail.
> Do the changes to Class.java and the enum optimal
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
fix license year in test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
-
On Thu, 17 Feb 2022 05:46:38 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix test
>
> test/jdk/java/util/Map/HashMapsPutAllOverAllocateTableTest.java line 2:
>
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
migrate to junit
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
migrate to junit
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
migrate to junit
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Thu, 17 Feb 2022 19:39:47 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> migrate to junit
well seem
On Fri, 18 Feb 2022 11:20:12 GMT, XenoAmess wrote:
> well seems jtreg cannot invoke Junit4 's parameterized test.
Nope, it can! :)
-
PR: https://git.openjdk.java.net/jdk/pull/7431
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with two additional
commits since the last revision:
- migrate to junit
- change threshold
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7
On Thu, 17 Feb 2022 05:45:54 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix test
>
> OK, good progress. Yes, leaving ConcurrentHashMap to another PR is fine.
>
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
revert unrelated changes and add it to ProblemList.txt
https://bugs.openjdk.java.net/browse/JDK-8282
On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote:
> Sigh. (I'm sighing at the author of the
> Enum/ConstantDirectoryOptimalCapacity.java test, not you.) What a mess. See
> https://bugs.openjdk.java.net/browse/JDK-8282120 which I just filed. The
> broken test and the OptimalCapacity utiliti
On Fri, 18 Feb 2022 18:53:43 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> revert unrelated changes and add
On Sun, 20 Feb 2022 16:12:08 GMT, Andrew Haley
wrote:
> I don't think this is terribly important, but I don't like to see attempts at
> hand optimization in the standard library.
OK, we've decided use that Math.ceil() solution.
-
PR: https://git.openjdk.java.net/jdk/pull/7431
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with three additional
commits since the last revision:
- refine test
- 1. optimize IdentityHashMap that when calling ::new(Map), do not call
map.size() twice but o
On Sun, 20 Feb 2022 18:04:50 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - refine test
> - 1. optim
On Sun, 20 Feb 2022 18:03:07 GMT, XenoAmess wrote:
>> XenoAmess has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - refine test
>> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call
On Sun, 20 Feb 2022 18:20:27 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - refine test
>> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call
On Sun, 20 Feb 2022 18:38:35 GMT, XenoAmess wrote:
>> src/java.base/share/classes/java/util/IdentityHashMap.java line 281:
>>
>>> 279: * @throws NullPointerException if the specified map is null
>>> 280: */
>>> 281: private Identit
On Sun, 20 Feb 2022 18:20:27 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - refine test
>> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call
On Sun, 20 Feb 2022 19:19:16 GMT, liach wrote:
>> Imo you should just remove the `if (expectedSize == 0)` check than using
>> this somewhat ugly trick to avoid calling `size()` twice (the second call is
>> only used for this relatively useless fast-path, especially for the
>> concurrent collec
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine IdentityHashMap
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
-
On Sun, 20 Feb 2022 19:11:26 GMT, liach wrote:
> > I don't thik it reasonable. or is there eveidence it be?
>
> If this map is too dense, there may be a lot of hash collisions, and the
> lookup performance would decrease because this hashmap is linear probe than
> red-black tree buckets like t
On Sun, 20 Feb 2022 20:02:09 GMT, XenoAmess wrote:
> You should run benchmarks to see how bad the lookup performance degrades
> after you saves memory used by the hash table.
OK, would find some time for it.
-
PR: https://git.openjdk.java.net/jdk/pull/7431
On Sun, 20 Feb 2022 20:03:07 GMT, XenoAmess wrote:
> > You should run benchmarks to see how bad the lookup performance degrades
> > after you saves memory used by the hash table.
>
> OK, would find some time for it.
@liach which jmh test should I run by the way?
Or is ther
On Mon, 21 Feb 2022 06:33:05 GMT, liach wrote:
> Unfortunately I don't think there is any for now.
@liach
Yes. that is why I ask if there be evidence to show `(int) ((1 + m.size()) *
1.1)` be an optimization, but not otherwise.
(IMO it is otherwise.)
-
PR: https://git.openjdk.ja
On Wed, 2 Mar 2022 01:44:24 GMT, Stuart Marks wrote:
> I'm starting to look at this again. First, a quick note -- I don't think
> there should be any IdentityHashMap changes here. That uses a completely
> different internal structure and allocation policy, and it's kind of a
> distraction from
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
revert changes to IdentityHashMap
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/fi
On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - migrate to junit
>> - change threshold
>
> Sigh. (I
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
cast several float to double before calculation
-
Changes:
- all: https://git.openjdk.java.net/
On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - migrate to junit
>> - change threshold
>
> Sigh. (I
On Fri, 4 Mar 2022 02:27:53 GMT, Stuart Marks wrote:
> OK, I took a look at HashMapsPutAllOverAllocateTableTest.java. It's certainly
> a good start at testing stuff in this area. However, I notice that
>
> ```
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java
> ```
>
> already exists and te
On Fri, 4 Mar 2022 02:27:53 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cast several float to double before calculation
>
> OK, I took a look at HashMapsPutAllOv
On Thu, 3 Mar 2022 15:46:37 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> cast several float to double
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Fri, 4 Mar 2022 17:43:25 GMT, liach wrote:
> nitpick for the test code: for better performance, move method handle and var
> handle to static final fields so the jvm can run faster
will do it when we really migrate this test, but it should be done in another
pr when I add WeakHashMap's tabl
On Fri, 4 Mar 2022 20:05:23 GMT, Stuart Marks wrote:
> This actually tests three things: 1) table is lazily allocated, 2) default
> capacity is 16, and 3) using putAll to populate the map with 64 elements
> results in a table size of 128. This should really be broken into three
> separate test
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with three additional
commits since the last revision:
- refactor tests
- refactor tests
- refactor WhiteBoxResizeTest
-
Changes:
- all: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refactor tests
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Sat, 5 Mar 2022 19:29:17 GMT, liach wrote:
> this looks wrong, and the class instance is used nowhere later. should
> probably be removed.
@liach already removed in the latest commit.
-
PR: https://git.openjdk.java.net/jdk/pull/7431
On Fri, 4 Mar 2022 21:02:50 GMT, Stuart Marks wrote:
>>> This actually tests three things: 1) table is lazily allocated, 2) default
>>> capacity is 16, and 3) using putAll to populate the map with 64 elements
>>> results in a table size of 128. This should really be broken into three
>>> separ
On Thu, 10 Mar 2022 01:11:03 GMT, Stuart Marks wrote:
> Sorry, the test changes look like they're heading in the wrong direction. I
> tried to provide some hints for what I was looking for in my previous
> comments. At this point, I felt it would have been too time-consuming to
> provide a bun
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with five additional
commits since the last revision:
- clean out tests
- Remove 'randomness' keyword.
- Cleanup and commenting.
- initi
On Thu, 10 Mar 2022 16:13:42 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with five additional
> commits since the last revision:
>
> - clean out tests
> - Rem
On Thu, 10 Mar 2022 16:15:03 GMT, XenoAmess wrote:
>> XenoAmess has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - clean out tests
>> - Remove 'randomness' keyword.
>> - Cl
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
manually create reference for ensuring test for WeakHashMap when
IntegerCache.high is configured/changed defa
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Thu, 10 Mar 2022 22:21:28 GMT, Stuart Marks wrote:
> The difficulty with having a loop instead of constants is that the expected
> value now needs to be computed. We could probably use `tableSizeFor` to do
> this. But this is starting to get uncomfortably close to a testing
> antipattern wh
On Thu, 10 Mar 2022 22:37:58 GMT, Roger Riggs wrote:
> Heads up here! java.lang.Integer is specified as a value based class and
> should not be used where identity is needed.
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
> I don't have a r
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Fri, 11 Mar 2022 01:28:13 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> refine test
oops seems I wrongll
On Fri, 11 Mar 2022 01:42:19 GMT, XenoAmess wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> refine test
>
> oops seems I wronglly added a teat case 0/1
> will delete it later
&
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with two additional
commits since the last revision:
- change KeyStructure to String
- fix test
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Fri, 11 Mar 2022 15:56:26 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - change KeyStructure to String
&
On Fri, 11 Mar 2022 19:09:25 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - change KeyStructure to String
>> - fix test
>
> test/jdk/java/util/HashMap/White
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: ht
On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - change KeyStructure to String
>> - fix test
>
> Regarding the number of te
On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks wrote:
> I think we can rely on the monotonicity of these functions. If populating a
> map both with 49 and with 96 mappings results in a table length of 128, we
> don't need to test that all the intermediate inputs also result in a table
> length
On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - change KeyStructure to String
>> - fix test
>
> Regarding the number of te
On Thu, 10 Feb 2022 17:46:36 GMT, XenoAmess wrote:
> 8281631: HashMap copy constructor and putAll can over-allocate table
This pull request has now been integrated.
Changeset: 3e393047
Author: XenoAmess
Committer: Stuart Marks
URL:
https://git.openjdk.java.net/jdk/com
On Wed, 16 Mar 2022 16:46:58 GMT, Stuart Marks wrote:
> No, you don't need to do any rebasing; when the change is integrated, all
> these commits will automatically be squashed into a single commit. If that
> can't be done, the bot will detect it and give a warning, which will probably
> inclu
On Thu, 17 Mar 2022 03:09:53 GMT, Stuart Marks wrote:
> There's already a bug for this:
> [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). This
> includes creating a new API as well as fixing up a bunch of call sites.
> There's a partial list of call sites in java.base there. G
8186958: Need method to create pre-sized HashMap
-
Commit messages:
- 8186958: Need method to create pre-sized HashMap
Changes: https://git.openjdk.java.net/jdk/pull/7928/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=00
Issue: https://bugs.openjdk.java.ne
On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote:
> 8186958: Need method to create pre-sized HashMap
@stuart-marks
I think making these functions at Collections is slightly better than place
them to their own classes.
The first step is to make such functions.
The second step is to cha
On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote:
> 8186958: Need method to create pre-sized HashMap
I do have a local test to make sure the 3 functions I provided can produce
equal capacity HashMap, but I think it does not need to be added into jdk.
import java.lang.reflect.Array;
imp
On Wed, 23 Mar 2022 21:26:02 GMT, liach wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> src/java.base/share/classes/java/util/Collections.java line 5826:
>
>> 5824: * @since 19
>> 5825: */
>> 5826: public static HashMap newHashMap(int expectedSize) {
>
> Stuart [in
On Thu, 24 Mar 2022 00:39:27 GMT, XenoAmess wrote:
>> src/java.base/share/classes/java/util/Collections.java line 5826:
>>
>>> 5824: * @since 19
>>> 5825: */
>>> 5826: public static HashMap newHashMap(int expectedSize) {
>
On Thu, 24 Mar 2022 04:52:16 GMT, David Holmes wrote:
> That isn't what is returned.
@dholmes-ora Yes it isn't actually. but I cannot find a better description
string for it.
"the pre-processed raw initial capacity for HashMap based classes." is more
exact but sounds weird.
Have you any sugg
On Thu, 24 Mar 2022 11:14:54 GMT, David Holmes wrote:
>>> That isn't what is returned.
>>
>> @dholmes-ora Yes it isn't actually. but I cannot find a better description
>> string for it.
>>
>> "the pre-processed raw initial capacity for HashMap based classes." is more
>> exact but sounds weird
> 8186958: Need method to create pre-sized HashMap
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
fix javadoc's @return
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7928/files
- ne
On Thu, 24 Mar 2022 11:14:54 GMT, David Holmes wrote:
>>> That isn't what is returned.
>>
>> @dholmes-ora Yes it isn't actually. but I cannot find a better description
>> string for it.
>>
>> "the pre-processed raw initial capacity for HashMap based classes." is more
>> exact but sounds weird
1 - 100 of 248 matches
Mail list logo