[crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2]

[Timofei Pushkin]

On Tue, 29 Jul 2025 06:37:06 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> So this is actually triggering the deoptimization (yes, the method sounds like that, but the error message sounds like it's just checking some statistics)? If the purpose of the test is to check that recompilations won't happen too soon, why is there a difference in the time when you trigger the deoptimization? (for delayMs == 0 this must be in the afterRestore, but why wouldn't you trigger it there even for delayMs > 0?)
>
>> So this is actually triggering the deoptimization
> 
> Yes, it triggers the deoptimization. It returns the amount of compilations actually deoptimized (can be zero if the method was not compiled; can be multiple for one method if there were OSR compilations with different entry byte codes, although I believe this overload skips OSRs).
> 
>> but why wouldn't you trigger it there even for delayMs > 0
> 
> Because then the test would succeed even if the delaying code gets removed, i.e. it won't actually be testing that the delay works.

It would be easier to test if after-restore recompilations would happen immediately instead of after the delay expires (then I could set a very large delay but after triggering the decompilation just wait a bit until it gets recompiled instead of having to wait until the delay expires). But that turned out to not be easy to implement (threads triggering decompilations sometimes cannot enqueue compilations), so it is something to maybe implement in the future.

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

PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2238693138