RFR: jsr166 jdk9 integration wave 12
martinrb at google.com
Tue Oct 18 23:18:26 UTC 2016
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?
> Also, some odd stylistic things, such as:
> while (s == (capacity = (elements = this.elements).length))
> Is this an attempt to help the JIT or something?
> "jsr166 style" - makes it easy on javac and the JIT, if not for humans.
More information about the core-libs-dev