RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback
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
+1
On May 19, 2020, at 10:59 AM, Claes Redestad <claes.redestad@oracle.com> 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
Thanks for reviewing, Jim! /Claes On 2020-05-19 16:05, Jim Laskey wrote:
+1
On May 19, 2020, at 10:59 AM, Claes Redestad <claes.redestad@oracle.com> 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
+1 Originally I thought this was a lost cause or too much effort given the edge case, but your prior fix and Peter’s nudging to “lazy” static values made it more viable. I agree with not changing the other strategies. Let's remove ‘em. Paul.
On May 19, 2020, at 6:59 AM, Claes Redestad <claes.redestad@oracle.com> 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
On 2020-05-19 17:22, Paul Sandoz wrote:
+1
Thanks!
Originally I thought this was a lost cause or too much effort given the edge case, but your prior fix and Peter’s nudging to “lazy” static values made it more viable.
Yeah, I had written it off as a lost cause too until Peter nudged me back on track. /Claes
I agree with not changing the other strategies. Let's remove ‘em.
Paul.
On May 19, 2020, at 6:59 AM, Claes Redestad <claes.redestad@oracle.com> 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
participants (3)
-
Claes Redestad
-
Jim Laskey
-
Paul Sandoz