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)
> 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
> 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 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.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:
> 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
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
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
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:
> 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
> 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 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
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
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
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
> 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
> 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 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: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
> 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:
> 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
>
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
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
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
>
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 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.
> 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: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 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
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
> 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 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
> 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.
- initial rewr
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
> 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
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.
>> - Cleanup a
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
>>>
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:
fix test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new: 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 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 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
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
> 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
> 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
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
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: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
> 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.
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
> 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
> 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 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
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'm
> 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
> 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'm
> 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
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
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 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
> 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 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 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.
>
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:
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=7928=00
Issue:
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
> 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
- new: ht
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
On Thu, 24 Mar 2022 11:15:12 GMT, David Holmes wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix javadoc's @return
>
> src/java.base/share/classes/java/util/Collections.java line 5
On Thu, 24 Mar 2022 00:44:02 GMT, liach wrote:
> Note that the methods may have to go to somewhere else in `java.util` if
> `Collections` cannot be loaded too early during startup, as HashMap is loaded
> very early
I'm afraid you are correct... moved the calculation function into HashMap
> 8186958: Need method to create pre-sized HashMap
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
move the static functions to map classes themselves.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7928/fi
> 8186958: Need method to create pre-sized HashMap
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
delete a space.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7928/files
- new: https://git.openjdk.java.
> 8186958: Need method to create pre-sized HashMap
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
use jmh Blackhole
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7928/files
- new: ht
On Wed, 23 Mar 2022 21:04:52 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use jmh Blackhole
>
> test/jdk/java/util/Collections/CalculateHashMapCapacityTestJMH.java l
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
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
On Thu, 24 Mar 2022 14:54:39 GMT, Roger Riggs wrote:
> It would be clearer with a comment on the constant or use the expression (the
> compiler will evaluate it). `Integer.MAX_VALUE / 4 * 3`.
@RogerRiggs
No, as `Integer.MAX_VALUE / 4 * 3` is actually 1610612733,
and
1 - 100 of 248 matches
Mail list logo
