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