On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz <marti...@google.com> wrote:
> > > On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich <vita...@gmail.com> > wrote: > >> >>> > * Change in allocation/capacity policy. >>> > >>> > The removal of the power-of-two restriction, and applying a 1.5x growth >>> > factor (same as ArrayList) seems sensible. Does this mean that the >>> ability >>> > to compute the proper array index by using x & (length-1) wasn't worth >>> it? >>> > Or at least not worth the extra tail wastage? >>> > >>> >>> There's no integer division to optimize, as with hash tables. >> >> But it does add some new branches, doesn't it? Potentially branches that >> aren't taken prior to JIT compilation, but taken later = deopt. >> > > If it's a smidgeon slower, I don't care that much; improvement in > flexibility and scalability are more important. > > Of course, I do care about algorithmic improvements to e.g. removeIf > > >> Curious if you ran some benchmarks on ArrayDeque. >> > > Not yet. Who would like to show how slow the code is? > I revived my ancient IteratorMicroBenchmark for the latest webrev, made it a proper jtreg test, added ArrayDeque Jobs, and verified that the new code is measurably faster than the old code, at least for the mundane job of iterating. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ArrayList/
