RFR: jsr166 jdk9 integration wave 12

Martin Buchholz 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
>> 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?

> 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 mailing list