Resync j.u.c and Update ConcurrentHashMap to v8 (original) (raw)
Doug Lea dl at cs.oswego.edu
Mon May 27 13:05:32 UTC 2013
- Previous message: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155
- Next message: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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> futures = new ArrayList<Future>(tasks.size()); + ArrayList<Future> futures = new ArrayList<Future>(tasks.size());
Are you suggesting that we not improve performance? :-) Waiting a decade in wishful-thinking mode about ArrayList traversal seems long enough.
(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.
-Doug
- Previous message: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155
- Next message: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]