+1
> On May 19, 2020, at 10:59 AM, Claes Redestad <[email protected]> > wrote: > > 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
