On 08/13/2013 09:54 PM, Doug Lea wrote:
On 08/12/13 16:30, Mike Duigou wrote:
Hi Doug;
Several minor recent cleanups and proposed cleanups in HashMap made
me wonder how things are progressing on this work. Do you feel it's
nearly ready to integrate into the jdk8 repos? What additional work
remains? Are you tracking changes going in to the jdk8 repos?
While I haven't touched it lately (I've been distracted with a
lot of other things), last I left it, it seemed integratable.
I haven't seen any list traffic that seems applicable,
except for Remi's, that I ought to reply to...
I've noticed that Doug's version doesn't have the patch from Igor
Gerasimov that
use Integer.highestOneBit to find the power of two.
It uses the same efficient tableSizeFor method CHM has used for a decade.
Why mess with success? :-)
I've checked, Integer.highestOneBit is not an intrinsic, and uses the
same trick, so I agree :)
And that the iterators on entrySet, keySet and values doesn't have
their method
forEachRemaining overriden
(unlike java.util.ArrayList).
Are you saying that all iterators should define forEachRemaining?
Seems excessive.
All iterators for ArrayList, HashMap and their views should have
forEachRemaining,
I don't care about the other collections :)
forEachRemaining internally use local variables instead of fields as the
traditional iterator does,
so it may be faster than a plain old iterator loop. Moreover, the call
to the Consumer inside
the default method defined in Iterable can be megamorphic,
if each iterator's view have they own implementation, you create a
several of different callsites
(I know, I know, it's a kind of poor's man optimization) that mitigates
the profile pollution problem.
-Doug
Rémi
Mike
On Jul 8 2013, at 08:24 , Doug Lea wrote:
On 07/05/13 04:55, Paul Sandoz wrote:
I played with these in the lambda repo.
I needed to make the following additional change for things to
compile:
--- a/src/share/classes/java/io/ExpiringCache.java Fri Jul 05
10:04:00 2013 +0200
+++ b/src/share/classes/java/io/ExpiringCache.java Fri Jul 05
10:45:10 2013 +0200
...
Thanks to those chasing this down, now recorded as a CR at:
http://bugs.sun.com/view_bug.do?bug_id=8017219
Some might think this is a fun javac corner case to read about,
but for present purposes, the moral is that the name of
the internal LinkedHashMap.Entry class, even though it is never
exported, cannot be changed without impacting re-compilability of
some external usages. Fine. We can cope.
For people still following along, see updates at...
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/HashMap.java?view=log
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/dl/java/util/LinkedHashMap.java?view=log
