RFR: 8347406: [REDO] C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash)

[Damon Fenacci]

On Thu, 20 Feb 2025 20:53:30 GMT, Dean Long <dlong at openjdk.org> wrote:

> I don't understand why JDK-8326615 didn't work. If the minimum codecache size was too small, can't we just increase it?

It seems that the small minimum codecache size wasn’t the core of the problem. In JDK-8326615 I’ve actually tried increasing the minimum code cache size (even calculating the minimum C1 and C2 sizes needed) but I kept hitting the same problem seemingly because what triggers the crash is the code cache exceeding its limits **exactly** during one of the allocations in the 4 call paths listed in the description (any allocation at another point simply turns off C1 or C2 (or both)). Increasing the minimum was possibly making it a bit less probable (i.e. when running something small that would use very little code cache, e.g. `java -version`) but as soon as running something a bit bigger (requiring more code cache), we could still end up calling the problematic allocations right when the code cache was full.
BTW even if the crash was very dependent on C1/C2 thread scheduling etc., I was able to reproduce it with different minimum code cache sizes relatively frequently.

Even so, it might be a good idea to additionally increase the minimum code cache anyway. @dean-long do you think it would make sense to file an RFE for that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23630#issuecomment-2687239402