Proposal: optimization of Map.copyOf and Collectors.toUnmodifiableMap

[Stuart Marks]

Hi Peter,

Sorry for the delay again. I got pulled into a P1 escalation.

I don't think I'll have time to look at this in any detail until after JDK 11 
ramp-down.

s'marks


On 6/22/18 9:51 AM, Peter Levart wrote:
> Hi Stuart,
>
> Do you still fear that "single-threaded-object" idiom is not safe?
>
> I would just like to comment on the last approach...
>
> On 06/19/2018 07:01 PM, Peter Levart wrote:
>> Here's another attempt that uses the same technique but relaxes the possible 
>> concurrent source map scenario (where number of pairs emitted by 
>> Map.forEach() doesn't agree with Map.size()):
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/UnmodifiableMap_copyOf/webrev.03/
>>
>> The construction is moved entirely into a separate MapBuilder object. The 
>> builder is used for Map.of(...) methods too.
>>
>> Here are the benchmark results that show improvements in every respect 
>> touched by the patch:
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/UnmodifiableMap_copyOf/UnmodifiableMapBench_results.txt 
>>
>>
>> Here are the JMH benchmarks used to produce these results:
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/UnmodifiableMap_copyOf/UnmodifiableMapCollectorBench.java 
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/UnmodifiableMap_copyOf/UnmodifiableMapCopyOfBench.java 
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/UnmodifiableMap_copyOf/UnmodifiableMapOfBench.java 
>>
>>
>>
>> So what do you think of this one?
>>
>> Regards, Peter 
>
> When this is used to copy concurrently changing concurrent Map, it has 
> approximately the same performance consequence as when using 
> Map.entrySet().toArray(). Either logic uses the estimated size to pre-size the 
> array, but when the size is a moving target, it fails, so it has to do another 
> copy at the end. My approach uses the estimated size to collect elements into 
> the ready-made hash-table. When it fails, it has to do another copy, but in 
> general case when the estimate is correct, it doesn't need an intermediary 
> representation in the form of array, so it can be more optimal.
>
> Regards, Peter
>