RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback

[Claes Redestad]

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 at 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
>