RFR: Store cpu features in AOTCodeCache header

[Radim Vansa]

On Tue, 8 Jul 2025 10:50:59 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Simply said if you store the compiled Java code on old CPU (almost no features) and then run it on new CPU (full features) then it will crash. It crashes when a newly compiled code calls the restored code or vice versa. If you disagree I can try to reproduce with Leyden, it was happening with CRaC.
>
> @jankratochvil I'm not disagreeing - merely wanting to see where CRaC goes wrong and why (noting that it is a slightly different circumstance to the AOT Cache case).
> 
> My preferred position would be that there /ought not/ to be any issues reusing code generated during the AOT Cache assembly phase in the absence of some given feature in combination with with code generated in a production run where that feature is present i.e. that that any incompatibility would constitute an error in the code generation scheme. I'd be very interested in any evidence you can provide to show that 1) such a code generation error exists or, worse, 2) my preference is unrealizable.

I can't find the logs from when I was investigating the issue, but AFAIR https://github.com/openjdk/crac/pull/103 was motivated by a bug that happened in compiler thread; it was going through some code that calculated buffer size for output code based on the availability of CPU features, and then it went to actually write down the instructions. When the checkpoint happened in the middle of this and the CPU got changed (we got a 'better' CPU) the decision in this codepath was changed, and resulted in a buffer overrun.
So it was rather a synchronization problem: some code was written assuming that the CPU features are runtime-constant, but these are not. There is certainly space for a better solution, but we would have to track through some complex code and make sure that it works on a 'snapshot' of features.

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

PR Review Comment: https://git.openjdk.org/leyden/pull/84#discussion_r2204219284