RFR: jsr166 jdk9 integration wave 12
martinrb at google.com
Fri Oct 21 19:32:50 UTC 2016
On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz <martinrb at google.com>
> On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich <vitalyd at gmail.com>
>>> > * 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
>>> > to compute the proper array index by using x & (length-1) wasn't worth
>>> > 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
More information about the core-libs-dev