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

[Radim Vansa]

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

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

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

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

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