RFR: 8222484: Specialize generation of simple String concatenation expressions
claes.redestad at oracle.com
Mon Apr 15 13:10:22 UTC 2019
thanks for reviewing, and it's fair that we seek to improve comments and
readability of this code while we're at it:
Also fixed so we're starting with the value of initialCoder() rather
than 0L for documentation purposes. Using initialCoder() is only
necessary when all operands to a concat expression are primitives,
since any Object argument will result in correct mixing in of the UTF16
bit if CompactStrings is disabled. Perhaps there's a small optimization
opportunity lurking here..
On 2019-04-15 14:37, Jim Laskey wrote:
> The StringConcatHelper::valueOf really should be
> StringConcatHelper::stringOf to clarify the result. Use here is unlike
> String::valueOf context where the result is logically String.
> StringConcatHelper::mix comments really should describe the encoding. If
> does a lot of handwaving re checking for overflow and mixing coder.
> -- Jim
>> On Apr 15, 2019, at 7:49 AM, Claes Redestad <claes.redestad at oracle.com
>> <mailto:claes.redestad at oracle.com>> wrote:
>> please review this enhancement to specialize a few simple and common
>> String concatenation patterns in the default strategy.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222484
>> Webrev: http://cr.openjdk.java.net/~redestad/8222484/open.00/
>> This reduces first-time bootstrap times for the targeted patterns from
>> ~20ms to be lost in the noise on my machine (so ~0.5ms), while being
>> peak performance neutral and not regressing bootstrap characteristics on
>> more complex patterns.
>> This also consolidates the String::concat method to reuse the optimized
>> method in StringConcatHelper, which speeds up that method by ~1.4x for a
>> few sampled inputs.
>> Testing: tier1-3
More information about the core-libs-dev