RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 25 Mai 2020 23:13:27
> Objet: Re: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers

> Hi Rémi,
> 
> in isolation (1) was the bigger win on most of my tests. I can split the
> three improvements apart, if you prefer.

no, i trust you,

> 
> 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.

> 
> /Claes

Rémi

> 
> On 2020-05-25 22:53, Remi Forax wrote:
>> Hi Claes,
>> do you have evaluated the improvement (1) in separation of the others ?
>> 
>> (2) or (3) are clearly improvement but (1) is a trade of because you are adding
>> a second lookup into another table and make prepender() less likely to be
>> inlined.
>> 
>> Rémi
>> 
>> ----- Mail original -----
>>> De: "Claes Redestad" <claes.redestad at oracle.com>
>>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Envoyé: Lundi 25 Mai 2020 22:23:23
>>> Objet: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers
>> 
>>> Hi,
>>>
>>> let's improve the StringConcatFactory a bit!
>>>
>>> - prependers where both prefix and suffix is null are common in typical
>>> expressions; caching these specifically is profitable
>>>
>>> - current prepender argument ordering is unfortunate: String prefix,
>>> <arg>, String suffix. This means we have to do two back-to-back
>>> insertArguments rather than one if they were grouped together
>>>
>>> - add a bridge to the String mix function in StringConcatHelper to avoid
>>> method handle invokes in the bootstrap path.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8245756/open.00/
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8245756
>>>
>>> All together I see a substantial improvement on a number of
>>> concatenation bootstrap tests. On one stress test[1] I get these numbers
>>> before:
>>>
>>>       4,257,229,918 instructions # 1.10 insn per cycle ( +- 0.84% )
>>>         847,230,764 branches # 504.826 M/sec ( +- 0.87% )
>>>          34,600,787 branch-misses # 4.08% of all branches ( +- 0.91% )
>>>         0.319545331 seconds time elapsed ( +- 1.18% )
>>>
>>> And after:
>>>
>>>       3,692,867,129 instructions # 1.10 insn per cycle ( +- 0.73% )
>>>         734,054,515 branches # 498.753 M/sec ( +- 0.74% )
>>>          30,699,692 branch-misses # 4.18% of all branches ( +- 0.75% )
>>>         0.295842958 seconds time elapsed ( +- 1.10% )
>>>
>>> So ~13% reduction on this test.
>>>
>>> Testing: tier1+2
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>> [1]
> >> http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java