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

[Andrew Dinn]

On Fri, 28 Feb 2025 20:36:23 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Refreshing my memory, isn't the real problem with trying to fix this with a minimum codecache size is that some of these stubs are not allocated during initial single-threaded JVM startup, but later when the first compiler threads start, and that allows other code blobs to fill up the codecache?
>
>> 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?
> 
> Sure, if it's still an issue.

@dean-long You are right that the root of the problem is delayed stub init when running in tiered mode. It's actually a race between the C1 and C2 threads to consume code cache space.

Neither C1 nor C2 can generate compiled method code before they have initialized their respective stubs. However, initialization of C2 stubs may potentially occur after a C1 compiler thread has initialized its own stubs and generated some number of C1-compiled methods.

Clearly that can't happen the other way around because in tiered mode a C2 thread will only end up compiling a method after 1) a prior C1-compiled method exists in the runtime and 2) its own stubs have been generated. An implication of 1) is that the C1 stubs have already been generated.

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

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