Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155

[Mike Duigou]

On May 27 2013, at 06:05 , Doug Lea wrote:

> On 05/24/13 23:17, Mike Duigou wrote:
> 
>> There's an awful lot here!
> 
> (It's been a long time since jdk7 :-)
> 
>> 
>> - It was surprising (and somewhat disappointing) to see changes like the following in various places. Is iterator creation that expensive? I'd hate to have to go back to using old style for loops everywhere.
>> 
>> -        List<Future<T>> futures = new ArrayList<Future<T>>(tasks.size());
>> +        ArrayList<Future<T>> futures = new ArrayList<Future<T>>(tasks.size());
>> 
> 
> Are you suggesting that we not improve performance? :-)
> Waiting a decade in wishful-thinking mode about ArrayList
> traversal seems long enough.

Nope, merely feeling the same disappointment that using the old style iteration is necessary.

> (Aside: We addressed this in stream Spliterators to the
> extent possible at library level. ArrayList.forEach of a fully
> resolved non-capturing lambda is around twice as fast
> as iterators.)
> 
>> 
>> - The default for getOrDefault() in ConcurrentMap shouldn't be removed.
>> 
>> - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not normally order preserving.
>> 
> 
> Thanks! Both the results of my not rechecking vs lambda versions
> (where a lot of this code has been running for a while now).
> Hopefully no other three-way diffs of jsr166, lambda, tl
> fell between cracks.

I will be especially watchfully this. Comparing this patch applied to TL versus current Lambda was one of the checks I plan to make before completing approval of this issue.

Mike