RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers

[Paul Sandoz]

I prefer the first revision from a simplicity perspective. 

Are there any measurable benefits in the subsequent revision? It requires some careful reading, where the logic in the prepender is duplicated in the layering of the computeIfAbsent functions. Which, if needed, is fine.

Are the existing test sufficient to cover these cases? You referenced ObjStringCombos and I wondering if that makes sense as a combo stress test? 

Paul.

> On May 26, 2020, at 9:20 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> On 2020-05-26 00:48, forax at univ-mlv.fr wrote:
>>> Not sure in which sense you mean inlining? Few of the methods in the
>>> bootstrap code are likely hot enough to see inlining by a JIT - and the
>>> resulting MHs should be identical, just not constructed over and over
>>> again.
>> I'm wondering if the code without the null tests was not simple enough to be inlined by c1,
>> the MH creations tends to do a lot of checks that can be removed even by c1.
> 
> Time spent in prepender() does not seem to be a significant contributor
> to bootstrap overhead - time spent in MHs.insertArguments is, though.
> 
> One thing that falls out naturally from this is that prefix can only be
> non-null on the first prepender: "foo" + a + "bar" + b ... will bind
> both "foo" and "bar" to the a-prepender, then b and subsequent
> prependers will never see a prefix constant since it will be bound in
> as a suffix of the preceding argument. Thus it makes sense to either
> provide a caching mechanism for prependers whose prefix arguments are
> pre-bound to null:
> 
> http://cr.openjdk.java.net/~redestad/8245756/open.01
> 
> We might be able to special-case the first prepender so that we can
> remove the prefix argument from prependers in general, which might make
> the final MH a bit smaller and easier for the JIT to optimize.
> 
> Testing: tier1+2
> 
> /Claes