RFR: 8222852: Reduce String concat combinator tree shapes by folding constants into prependers
claes.redestad at oracle.com
Fri Apr 26 16:13:35 UTC 2019
Not content with the fact that we generate one tree for "foo"+bar+baz
and another for foo+bar+"baz", I did a little "Hold my beer!"-style
experiment with a constant folder that greedily folds prefix and suffix
constants around an argument (so "foo"+bar would be prepended in one go,
and bar+"baz" in one go in the other tree, making the stem of both trees
shareable with no trailing constants having to be filtered in).
And it works!
It doubles the amount of statically defined prependers from 14 to 28,
but halves the theoretical maximum number of (larger and more expensive)
MH combinator trees.
While I can see significant startup improvement on a range of tests
with this - and especially so for small, realistic ones - it's also a
bit of a mess. I will consider doing this as an immediate follow-up RFE,
if I can only clean it up to a point where the added bloat is
acceptable. One way to clean things up is to move from inner classes to
lambdas (like I've partially done already in this experiment). Turns out
to be effectively startup neutral here.
On 2019-04-26 15:55, Claes Redestad wrote:
> Hi Peter,
> thanks for looking at this!
> On 2019-04-26 11:08, Peter Levart wrote:
>> Hi Claes,
>> I wonder if it is even possible to create a test that would do
>> something like the following:
>> String s = ...
>> String s2 = s + "const1" + "const2" + s;
>> ...since javac concatenates consecutive constants into a single
>> constant. So this actually becomes:
>> String s2 = s + "const1const2" + s;
>> ...in bytecode.
>> So what do you think? Is it important to test this or is it
>> "obviously" correct?
> Adding an explicit sanity test for this seems reasonable to me, since
> it's a case allowable by the StringConcatFactory that is not expressible
> via javac:
> Also cleaned up a few unused imports etc.
More information about the core-libs-dev