That's nice ! In StringConcatFactory, i will change prefixConstant + constantValue (resp suffixConstant + constantValue) to prefixConstant.concat(constantValue)
to not depend on any string concat implementations of javac. regards, Rémi ----- Mail original ----- > De: "Claes Redestad" <claes.redes...@oracle.com> > À: "Peter Levart" <peter.lev...@gmail.com>, "Aleksey Shipilev" > <sh...@redhat.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Lundi 29 Avril 2019 11:34:11 > Objet: Re: RFR: 8222852: Reduce String concat combinator tree shapes by > folding constants into prependers > Hi Peter, > > On 2019-04-28 23:34, Claes Redestad wrote: >>>> >>>> What do you think? >>> >>> This is what I meant by "simplified wiring logic": >>> >>> http://cr.openjdk.java.net/~plevart/jdk-dev/8222852_StringConcatOpt/webrev.02p/ >>> >>> >>> I haven't tried this though, but if it works correctly and if JIT >>> inlines the strategy for each call site, it should also eliminate the >>> dead code paths that are detected from null/non-null bound constants >>> and the end result should be equivalent machine code. But that's just >>> in theory... >> >> thanks for picking this up and experimenting further with it! > > having run the numbers on your patch, I'm warming to this approach: > > - It seems the branches testing for null do get eliminated (no > regressions in neither existing nor new micro trying to provoke > pollution between LFs) > - Startup numbers generally a bit better, and the amortized/repeated > bootstrap cost of always binding in prefix and suffix appears to be > insignificant > - The logic for handling constants is nicer and less spread out; bonus > points for folding successive suffix constants! > > http://cr.openjdk.java.net/~redestad/8222852/open.03/ > > I merged some of the cleanups and comments and think this is good to > go rather than splitting it up into a follow-up RFE. > > Thanks! > > /Claes
