RFR: 8222852: Reduce String concat combinator tree shapes by folding constants into prependers
Claes Redestad
claes.redestad at oracle.com
Tue Apr 23 12:07:11 UTC 2019
On 2019-04-23 13:27, Aleksey Shipilev wrote:
> On 4/23/19 1:05 PM, Claes Redestad wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222852
>> Webrev: http://cr.openjdk.java.net/~redestad/8222852/open.00/
>
> Cool. Do we see the real-world examples where this helps? E.g. larger applications that have lots of
> concats? Asking because most apps do not have lots of concat shapes to begin with.
I can see some real but modest gains at use sites in the JDK code, e.g.,
java.util.logging bootstraps a few variants, and you get small
improvements already on bootstrapping obj + "foo" + obj at one site and
"foo" + obj + obj at another (-8 classes).
Most "real-world" benchmarks we run have not been built with a release
target of 9 or above, and even if they had most libraries they use are
likely to stay 8 compatible for some time. So it's anyone's guess what
gains we'd be able to expect on modern real-world applications.
>
> I'd keep the switch in the second loop, like this:
>
> for (RecipeElement el : recipe.getElements()) {
> switch (el.getTag()) {
> case TAG_ARG:
> ...
> break;
> case TAG_CONST:
> // Constants are already handled in the code above.
> break;
> default:
> throw new StringConcatException("Unhandled tag: " + el.getTag());
> }
> }
I figured that since the first switch would already check for unhandled
tags then a single test for TAG_ARG would suffice in the second, but I
have no strong opinion. Just thought it simplified the code flow a bit.
Thanks!
/Claes
More information about the core-libs-dev
mailing list