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

[Timofei Pushkin]

On Tue, 29 Jul 2025 08:45:34 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> 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.
>
>> 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.
> 
> And can't you test `whiteBox.getMethodCompilationLevel()` and ensure that the method is still deoptimized? That'd be prone to timing as well, but you could check timestamp after the level check and invalidate it if it's too late...

IIUC that would be essentially the same thing just tested the other way: we are still checking that the delay is long enough for this machine. And we would still need the timestamp check to check that the check itself did not happen too late, so there will still be two checks.

Also I consider optimizing the implementation in the future to recompile things recorded during C/R right after restore and start a new recording for the delay (this would recompile during-C/R decompilations earlier potentially improving the performance) — such implementation would require the test to be as it is now.

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

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