On 2020-05-14 17:05, Jim Laskey wrote:
Will this have an effect on JDK-8218173
<https://bugs.openjdk.java.net/browse/JDK-8218173> ?
Interesting that you ask, since this cleanup was extracted from an
attempted fix for 8218173.
_Potentially_ this helps. But it won't fix it.
Ensuring SCF.class is initialized reduces risk that we'll hit certain
OOMEs when going into the BSM in a constrained environment, but doesn't
eliminate the corner case in 8218173 entirely.
Initializing the strategy up front might solve more of the issues
in 8218173, but it's a slippery slope and it'd regress startup (likely
adds ~5ms to startup due the MH lookups). As I was looking at an eager
initialization I ran into weird bootstrapping issues, too, so I've
backed away from trying to solve 8218173.
/Claes
On May 14, 2020, at 11:39 AM, Claes Redestad
<claes.redes...@oracle.com <mailto:claes.redes...@oracle.com>> 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
