RFR: 8245024: Simplify and eagerly initialize StringConcatFactory

[Mandy Chung]

Hi Claes,

Is the bootstrapping issue contributed by Class::getDeclaredConstructors 
call in InnerClassLambdaMetafactory::buildCallSite?

I wonder how much performance gain compared to using 
Lookup::findConstructor for non-capturing lambda case.   If LMF uses 
Lookup::findConstructor, it does not perform any security permission 
check since it's a full privileged lookup and address JDK-8155659 lambda 
bootstrapping issue with security manager.   Is it easy to measure the 
performance difference?

Mandy

On 5/14/20 7:39 AM, Claes Redestad wrote:
> Hi,
>
> JDK-8155090 added some measures to StringConcatFactory to prevent
> certain bootstrapping issues. I think we should consider eagerly
> initializing the StringConcatFactory base class during bootstrap
> instead.
>
> Doing so will add a tiny bit of class loading overhead to bootstrap
> (which of course will be amortized on first use of SCF) but still this
> would also be a good opportunity to clean up a little.
>
> One straightforward means to do so is to move the CACHE, DUMPER and
> CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the
> only place where they are used (the MethodHandle based strategies don't
> manually spin classes and rely on LF sharing to de-duplicate shared
> components).
>
> Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8245024
>
> This reduces initialization overhead and simplifices bootstraps for the
> default case, while still passing relevant test cases such as test/jdk
> /java/lang/String/concat/WithSecurityManager.java for all strategies.
>
> Testing: tier1-2
>
> Thanks!
>
> /Claes