RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback
Claes Redestad
claes.redestad at oracle.com
Tue May 19 13:59:38 UTC 2020
Hi,
while hard to reproduce, it's possible to break the StringConcatFactory
if trying to bootstrap a concatenation when the VM is in such a state
that any allocation will throw an OOME
By eagerly initializing the default strategy classes during bootstrap,
while lazily initializing any method handles it uses in a way that
allows retries later if that fail, we should minimize the risk of this,
while ensuring we can recuperate.
This loads and initializes a few more classes eagerly on bootstrap, but
the initial startup cost of that sits well below 0.1ms (amortized on
first concat bootstrap), which seems a reasonable cost for increased
stability in constrained environments.
I've not attempted a fix for the non-default strategies. Our intent is
to remove these alternative strategies.
Bug: https://bugs.openjdk.java.net/browse/JDK-8218173
Webrev: http://cr.openjdk.java.net/~redestad/8218173/open.00/
Testing: tier1-3
This might also resolve https://bugs.openjdk.java.net/browse/JDK-8218176
- so I included the removal of TestStressG1Humongous from ProblemList-
graal.txt. I've run it a few times locally and in our CI without issue,
but we probably need to enable it for while to determine if the
intermittent issue is gone for good (or if we just move the issue
somewhere else).
Thanks!
/Claes
More information about the core-libs-dev
mailing list