Possible HashMap update

[Remi Forax]

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 
>>>
>>
>>
>